Egne images

Upload dit eget VM-diskimage — et hærdet basisbuild, et golden image fra din CI-pipeline, en appliance — og start instanser fra det. Et eget image tilhører den tenant, der uploadede det: kun den tenant kan se det, og kun den tenant kan boote fra det. Det optræder ved siden af platformens katalog alle de steder, hvor et image vælges.

Hvad du kan uploade

• Formater: qcow2 og raw (containerformat bare). Intet andet — en vmdk, vhd eller vdi skal konverteres lokalt først, f.eks. qemu-img convert -O qcow2 disk.vmdk disk.qcow2.
• Op til 35 GiB uploadet — selve filen. En større fil afvises af lagringskanten, før imaget importeres.
• Op til 35 GiB udvidet — imagets virtuelle størrelse (se nedenfor). Et større afvises ved importen.

Da en raw-fil er sin egen virtuelle størrelse, er et raw-image i praksis begrænset af upload-grænsen på 35 GiB. Brug qcow2 til alt, der er større.

En qcow2 afvises også, hvis den angiver en backing-fil, er krypteret eller har en anden version end 2 eller 3 — og det samme gælder enhver fil, hvis reelle format ikke stemmer med det disk-format, du har angivet. Backing-filen er den almindeligste årsag: et image bygget med qemu-img create -b, eller taget fra en snapshot-kæde, refererer til en anden fil, som platformen aldrig vil have. qemu-img convert -O qcow2 src.qcow2 flat.qcow2 flader kæden ud til et selvstændigt image.

Det er den udvidede størrelse, der tæller

En qcow2 er komprimeret og sparse, og Frostmoln konverterer den til raw under importen. Det, der lagres, er derfor imagets virtuelle størrelse — og den virtuelle størrelse er det, din kvote belastes med, det, du faktureres for, og det, en flavors rod-disk skal være stor nok til at rumme.

Det overrasker mange: en qcow2 på 800 MB, der beskriver en disk på 10 GB, bliver til et image på 10 GB. Tjek det, før du uploader:

qemu-img info debian-13.qcow2
# virtual size: 10 GiB (10737418240 bytes)   <- det er det, der tæller
# disk size: 794 MiB                         <- det er kun uploaden

Hvis den virtuelle størrelse er større, end du har brug for, så byg imaget med en mindre virtuel disk. (qemu-img resize --shrink kan skære den ned bagefter, men kun efter at filsystemet inde i imaget er krympet — ellers afkorter du det.)

Dit image vises som raw

Konverteringen er grunden til, at størrelsen ændrer sig, og den ændrer også formatet. Uploader du en qcow2, rapporterer platformen — når importen er gennemført — imaget som raw, både i portalens Format-kolonne og i fm compute image get. Det er ikke en fejl, og intet er gået tabt: raw beskriver det, platformen nu lagrer, nemlig det udvidede image, som konverteringen frembragte. Så længe imaget stadig står som Afventer upload eller Importerer, rapporteres det format, du angav.

Terraform er undtagelsen, og det er med vilje: disk_format på et frostmoln_image er en værdi, du konfigurerer, og en refresh overskriver den aldrig, så din state bliver ved med at sige qcow2. (Hvis den blev overskrevet, ville hver apply fejle med "provider produced inconsistent result after apply".) Image-datakilderne rapporterer slet ikke noget diskformat.

Frostmoln gemmer ikke, hvilket format du uploadede, så der er intet at sammenligne et image med senere. Notér selv, hvilket build et givet image stammer fra — feltet beskrivelse er et godt sted til det.

Klargør imaget, før du uploader det

Et image er et helt filsystem, og alle i din tenant kan starte en instans fra det og læse det som root. Alt, hvad dit build har efterladt, følger med.

• Fjern legitimationsoplysninger. Private SSH-nøgler, authorized_keys, cloud-init-tilstand (/var/lib/cloud), API-tokens, registerlogins, .env-filer, shell-historik, legitimationsoplysninger til pakkehåndtering.
• Fjern SSH-værtsnøglerne (/etc/ssh/ssh_host_*), og tøm /etc/machine-id. Lader du dem blive, præsenterer hver eneste instans, der startes fra imaget, den samme værtsidentitet, og verifikation af værtsnøgler kan ikke længere skelne dine instanser fra hinanden.
• Lad cloud-init være installeret og aktiveret — på et Linux-image. Det er cloud-init, der installerer dine registrerede SSH-nøgler, kører dine brugerdata og anvender en konsoladgangskode ved første boot. Et Linux-image uden cloud-init kommer op uden nogen vej ind — og omgå ikke det ved at bage en adgangskode eller en fast authorized_keys ind i imaget. En konsoladgangskode, der bestilles til et sådant image, accepteres og ignoreres derefter i stilhed, fordi der ikke er noget i imaget til at anvende den — medmindre imaget ikke angiver nogen distribution, platformen kender, og i så fald fejler starten i stedet. Windows er undtagelsen fra dette punkt — se Windows-images.
• Behold ConfigDrive på cloud-inits liste over datasources. Dine SSH-nøgler, brugerdata og konsoladgangskode ankommer på en lille skrivebeskyttet disk, der tilknyttes instansen, ikke over netværket. Almindelige cloud-images accepterer den allerede, fordi ConfigDrive står på cloud-inits standardliste over datasources, så det har kun betydning, hvis dit build indsnævrer den liste. Sætter du datasource_list eksplicit, så behold ConfigDrive i den — datasource_list: [ConfigDrive] er nok. Et image, der kun accepterer en netværksbaseret datasource, kan komme op uden nøgler og uden brugerdata. På Windows dækker cloudbase-inits ConfigDriveService det samme.
• Du ejer selv patchningen af det. Et eget image er frosset i det øjeblik, du uploader det. I modsætning til platformens katalog er der intet, der opdaterer det for dig: byg et nyt, og upload det, når dets pakker skal patches.

Windows-images

Frostmoln sætter ingen legitimationsoplysninger inde i en Windows-gæst. Indsprøjtning af SSH-nøgler, konsoladgangskoden og den administrerede agent er alle cloud-init-mekanismer, og der findes ikke noget API til at hente en adgangskode — en konsoladgangskode afvises blankt for et image, der angiver Windows. For Windows er cloud-init-punktet ovenfor derfor vendt om: legitimationsoplysningerne skal komme fra dig. Windows er ikke et testet platformsimage; alt nedenfor er det, hypervisoren kræver af det image, du bygger.

Byg det som BIOS/MBR, ikke UEFI. Instanser booter på maskintypen i440fx med en legacy-BIOS; platformen har ingen UEFI-firmware, og hverken portalen, CLI'en eller Terraform giver mulighed for at bede om UEFI eller Secure Boot. Et moderne standardbuild — Hyper-V Generation 2 eller en hvilken som helst UEFI/GPT-disk — har ingen bootbar MBR og hænger på "no bootable device". Brug Hyper-V Generation 1 eller det tilsvarende BIOS/MBR-layout i dit byggeværktøj. Hyper-V giver dig desuden en vhdx, som ikke er et accepteret uploadformat: konvertér den først med qemu-img convert -O qcow2 disk.vhdx disk.qcow2.

Medtag virtio-driverne. Rod-disken tilknyttes på virtio-bussen, og netkortet er en virtio-model — det er standarden for hver eneste instans, og hverken portalen, CLI'en eller Terraform giver dig mulighed for at ændre nogen af delene. Slipstream eller installér virtio-win-driverne før sysprep: viostor er kritisk for boot, NetKVM er netkortet. Uden dem giver Windows bugcheck 0x7B INACCESSIBLE_BOOT_DEVICE ved første boot eller kommer op uden netværk. Der findes ingen redningsvej og ingen image-egenskab, der retter det bagefter: du bygger om og uploader igen.

Dimensionér selv den virtuelle disk. New-VHD bruger som standard 127 GB dynamisk voksende, og det er den virtuelle størrelse, loftet på 35 GiB måler, uanset hvor tom filen er — derfor afvises et Hyper-V-standardbuild ved importen, selvom den fil, du uploadede, var lille. Opret disken på 32 GiB eller mindre.

Forvent et UTC-ur. Hypervisoren får aldrig at vide, at gæsten er Windows — os_distro er et signal på Frostmoln-laget, og den separate egenskab, platformen læser til dette, er ikke noget, portalen, CLI'en eller Terraform kan sætte — så det virtuelle RTC kører UTC, og Windows læser det som lokal tid. Sæt RealTimeIsUniversal (DWORD 1) under HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation i imaget, eller lev med en forskydning i uret.

Sådan kommer du ind

Har dit image cloudbase-init med, så foretræk den. Brugerdata leveres stadig til instansen, så cloudbase-init kan forbruge dem, og du kan sætte Administrator-adgangskoden fra dine egne brugerdata pr. instans og give hver instans sin egen. Frostmoln sætter hverken den adgangskode for dig eller tester denne vej — men intet blokerer den, og den undgår den fælles hemmelighed nedenfor. Tilknyt ikke en SSH-nøgle til en Windows-instans: ingen nøgle når nogensinde frem til gæsten, og det omskriver de brugerdata, cloudbase-init læser — flettet ind i din #cloud-config eller pakket om som multipart — helt uden gevinst.

En adgangskode i brugerdata er dog ikke skjult. Brugerdata når frem til instansen på config-2-drevet — en ganske almindelig cd-rom-volumen, som Windows monterer ligesom enhver anden — og cloudbase-init skriver dem også til sin egen log. Gå ikke ud fra, at kun en administrator kan læse nogen af delene. Det er også en bootstrap-legitimation: skift den ved første login, og hold den ude af en startskabelon, hvis brugerdata alle i din tenant kan læse.

Ellers bag legitimationsoplysningerne ind i imaget — sæt Administrator-adgangskoden, eller opret en konto, under sysprep / din unattended-installation — og nå dem via konsollen. Det er den understøttede vej, ikke en nødløsning. Vær dog klar over, hvad den hemmelighed er: en bootstrap-legitimation, der er identisk på hver eneste instans, som nogensinde startes fra det image, læsbar for alle i din tenant, der kan boote det (se ovenfor), og en sletning af imaget tilbagekalder den ikke på instanser, der allerede kører. Skift den ved første login.

• Fjern legitimationsoplysningen dér, hvor installationen efterlod den. Sysprep og unattended-installation efterlader den 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. Brug aldrig AutoAdminLogon — den skriver adgangskoden til registreringsdatabasen i klartekst. Windows-modstykkerne til punktet om at fjerne legitimationsoplysninger ovenfor gælder også: Credential Manager, gemte RDP-legitimationsoplysninger, ConsoleHost_history.txt og produktnøglen.

Uanset hvilken vej du vælger:

• Vælg en adgangskode, du kan taste på et amerikansk tastatur. Konsollen er en VNC-session med et en-US-tastaturlayout, så å, ä, ö — og alt andet, der kræver et nordisk layout — kan ikke tastes der. I modsætning til Linux findes der ingen SSH-nøgle som reserve, så en adgangskode, der ikke kan tastes, betyder en instans, du ikke kan nå. Brug printbar ASCII på amerikanske tastaturpositioner, lad imagets tastaturlayout stå på US, indtil du har en anden vej ind, og husk, at Windows kan låse kontoen efter gentagne mislykkede forsøg.
• Tag imaget med sysprep /generalize /oobe /shutdown. Det er Windows-udgaven af at fjerne SSH-værtsnøglerne: uden det deler hver instans fra imaget ét SID, ét RDP-certifikat og ét sæt DPAPI-maskinnøgler.
• Angiv os_distro som windows, når du opretter imaget: --os-distro windows i CLI'en, OS-distribution i portalen, os_distro på et frostmoln_image i Terraform. Det kan ikke ændres bagefter — et image, hvor det blev sat forkert, skal uploades på ny — og det er det eneste felt, portalen, CLI'en og Terraform stiller til rådighed, som fortæller platformen, at imaget er Windows. Det har betydning, når nogen beder om en konsoladgangskode: starten fejler så med console password is not supported for Windows images i stedet for det mere vage cannot determine the default user for this image; omit the console password or use an SSH key, som aldrig nævner distributionen — og som det på et Linux-image er at navngive login-brugeren, der løser. Mærk aldrig et Windows-image med en Linux-distribution for at komme forbi den besked — så accepterer platformen konsoladgangskoden og gør i stilhed ingenting med den.
• Bed ikke om den administrerede agent (--instance-access, instance_access = true). Den kræver systemd og cloud-init og er derfor kun til Linux. Anmodningen afvises ikke: instansen oprettes normalt, agenten bliver aldrig installeret, og fm shell (tidligere fm ssh) fejler senere med besked om at oprette instansen på ny med det flag, du allerede brugte.
• Kom ind via konsollen. Konsol på instansen i portalen eller fm compute instance console <instance>, som udskriver en konsol-URL. Det er en noVNC-session, og det er den eneste konsol, platformen leverer. Det er ikke en måde at få RDP på.
• Åbn derefter din egen fjernadgang — snævert. Log ind på konsollen, opsæt selv RDP eller WinRM, og åbn for det i en sikkerhedsgruppe — aldrig mod 0.0.0.0/0. Intet er åbent som standard. Foretræk at nå instansen på dens private adresse over en VPN eller en bastion, hold NLA aktiveret, og kør WinRM over HTTPS (5986), aldrig ukrypteret 5985.

Windows-licensering skal du selv medbringe og selv overholde. Frostmoln leverer hverken Windows-licens, nøgle eller aktiveringstjeneste, så et KMS-aktiveret image mister aktiveringen her — brug MAK eller et KMS, dine instanser kan nå.

Installér ikke en gæsteagent

Frostmoln bruger ikke qemu-guest-agent til noget, og du bør heller ikke bage Frostmolns egen agent ind i imaget.

Frostmoln installerer sin agent, når instansen oprettes, og kun hvis du beder om det — fm compute instance create --instance-access eller instance_access = true på en frostmoln_instance i Terraform. Den kan ikke tilføjes til en instans, der allerede findes: opret i stedet instansen på ny.

Den kan ikke være en del af imaget: agentens identitet er instansens eget id, som endnu ikke findes, mens du bygger imaget, så en indbagt kopi ville hverken have en identitet eller nogen måde at få en på.

Det, imaget skal stille til rådighed, er det, installationsprogrammet har brug for ved første boot:

Krav	Hvorfor
x86_64	Den eneste arkitektur, agenten er bygget til.
systemd som init, med systemctl i PATH	Agenten installeres som en systemd-tjeneste.
cloud-init, der kan rapportere instansens id	Den kører installationsprogrammet, og installationsprogrammet spørger den om instansens eget id — som er agentens identitet. Den falder tilbage til at læse config-drevet, hvilket kræver mount og sed.
sha256sum	Den hentede agent kontrolleres mod et fastlåst digest.
curl eller wget	Til at hente agenten.
Udgående HTTPS til Frostmolns agent-gateway, permanent	Ikke kun til download — den installerede agent holder en udgående forbindelse til gatewayen, og det er den, der bærer dine sessioner. Se noten nedenfor.
Et eksisterende /usr/local/bin og skrivbare /etc + /etc/systemd/system	Hvor binæren, dens konfiguration og dens unit skrives. Installationsprogrammet opretter ikke /usr/local/bin.

Et manglende værktøj fejler i stilhed

Det har størst betydning for slankede og minimale images. Mangler noget af ovenstående, booter instansen normalt og får blot aldrig nogen agent — der kommer ingen fejl ved oprettelsen, og fm shell til den vil ikke virke.

Hvor du skal kigge: /var/log/frostmoln-managed-agent-install.log på instansen angiver årsagen, og det samme gør den serielle konsol. cloud-init status --long rapporterer også en fejl, fordi en mislykket installation afslutter med en anden værdi end nul — så på en ellers sund instans er en mislykket tilmelding det, der gør cloud-inits endelige status rød.

Udgående trafik er den, der fejler efter en ren installation

Alle andre krav fejler højlydt i den log. Det gør udgående trafik ikke: agenten installeres helt korrekt, hvis gatewayen kan nås under første boot, og bliver derefter tavs, hvis du lukker for udgående trafik bagefter. fm shell holder op med at virke, uden at noget i installationsloggen forklarer det, fordi installationen lykkedes.

Din tildeling

Som standard må hver tenant eje 10 egne images på i alt 376 GB lagrede imagedata (decimale GB, talt på den udvidede størrelse). Snapshots og platformens katalog tæller ikke med. Det er en tildeling, ikke en pris: snapshots har deres egne grænser og faktureres separat — se Snapshots.

Dit aktuelle forbrug finder du i portalen under Kvoter, kategorien Egne images. Kontakt support for at få tildelingen hævet.

Der kan komme tre forskellige afvisninger under upload, og de har ikke samme løsning:

Status	Betydning	Hvad du gør
409 quota_exceeded	Din tildeling er fuld.	Slet et eget image for at frigøre en plads. Det hjælper aldrig at prøve igen.
403 quota_exceeded	For meget er allerede undervejs — for mange images afventer upload, eller for mange bytes ligger i mellemlager.	Færdiggør eller slet de images, der står i Afventer upload, og prøv så igen.
429	Du har startet for mange uploads inden for den seneste time.	Vent, til tidsvinduet er passeret. Et image, du allerede har oprettet, er der stadig.

En mislykket import bliver ved med at optage en plads

En mislykket import efterlader imaget i Afventer upload, så det tæller fortsat med i grænsen for igangværende uploads. Derfor forsvinder en 403ikke altid af sig selv — slet de images, du ikke har tænkt dig at færdiggøre.

Sletning af et image frigør dets plads med det samme — men først når intet bygger på det.

Et image, som lagringsbackenden stadig refererer til, kan ikke slettes

Hver instansdisk er en copy-on-write-klon af det image, den blev startet fra, så platformen afviser sletningen med en 409, så længe bare én af de kloner findes. Slet de instanser, der er startet fra imaget, og prøv så igen.

En afvisning ændrer ingenting: imaget er der stadig, stadig Aktiv, og den samme sletning lykkes, når den sidste klon er væk.

Upload fra portalen

Compute → Images → Upload image. Du angiver et navn, diskfilen, diskformatet og eventuelt en beskrivelse, OS-distribution, OS-version og arkitektur. Kun description og osVersion er rent beskrivende: osDistro er det, platformen udleder login-brugeren af, og det, som Windows-afvisningen af konsoladgangskoder læser, og architecture matches mod hypervisoren, når en instans placeres — derfor tager det x86_64 og intet andet, da det er den eneste værtsklasse, platformen kører. osDistro kan ikke ændres, efter imaget er oprettet.

Bag knappen kører portalen fire trin: den opretter imaget, sender filen direkte til objektlagringen (imagets bytes passerer aldrig API'et), beder platformen om at importere det og poller derefter, indtil det er klar. Konverteringen sker på serversiden og er proportional med imaget, så et stort image kan tage flere minutter; du kan forlade siden — importen fortsætter uden browseren.

Imagets status fortæller dig, hvor det er:

Status	Betydning
Afventer upload	Imaget findes, men indeholder endnu ingen bytes.
Importerer	Bytene konverteres og lagres.
Aktiv	Klar til at boote.
Import mislykkedes	Bytene blev afvist — se Når en import mislykkes.

En upload, der afbrydes halvvejs, efterlader imaget i Afventer upload. Opret ikke et nyt: brug Upload igen på den eksisterende række for at færdiggøre det.

Upload 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ører hele forløbet — opret, upload, importér — og udskriver imagets id, så snart imaget findes, altså før uploaden begynder, så en senere fejl aldrig mister det. (Under -o json / -o yaml kommer dokumentet, og dermed id'et, til sidst i stedet.) --wait blokerer, indtil imaget er aktivt (op til --timeout, som standard 30 minutter); uden det fortsætter importen på serversiden, og fm compute image get viser resultatet.

Hvis uploaden fejler eller afbrydes, findes imaget stadig — fyld det ud i stedet for at oprette et nyt:

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

Resten af familien:

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

Kun --name, --description, --min-disk og --min-ram kan ændres, efter et image er oprettet. Alle flag: fm CLI-referencen (på engelsk).

list udskriver den rå status, hvor en mislykket import ikke kan skelnes fra et image, der aldrig blev uploadet — begge viser queued. Brug get, som siger det eksplicit.

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 læses af den maskine, der kører Terraform — ikke en bucket-nøgle eller en URL. Terraform kan ikke se en ændring i filens indhold under en uændret sti, så kombinér den med source_file_hash, når du bygger imaget om på stedet: et ændret hash erstatter imaget, hvilket uploader og importerer det på ny. terraform import understøttes bevidst ikke — deklarér imaget i konfigurationen, og kør apply. Bemærk, at platformen sætter min_disk ud fra imagets reelle udvidede størrelse under importen og dermed erstatter det, du havde konfigureret; et konfigureret min_disk_gb bliver stående i state, som du skrev det, så en senere refresh kan vise platformens tal som en diff.

Fuldt skema og datakilderne til at slå et eksisterende image op (på engelsk):

• frostmoln_image-ressourcen
• frostmoln_image-datakilden · frostmoln_images-datakilden

Start en instans fra det

Dine images optræder alle steder, hvor et image vælges — portalens formular til at oprette en instans, fm compute instance create --image <image-id>, image_id i Terraform.

Snapshots af instanser tilbydes også der, i deres egen gruppe — se Snapshots.

Kun et Aktivt image kan boote. Vælgeren viser dine images uanset deres tilstand, så et image i kø eller et mislykket bliver tilbudt ligesom alle andre, og oprettelsen af instansen fejler så. Tjek status først.

Under importen registrerer platformen imagets minimumsdisk ud fra dets reelle udvidede størrelse og erstatter dermed enhver værdi, du har sat. En flavor, hvis rod-disk er mindre end det, kan ikke boote imaget.

Login-brugeren

Platformen udleder, hvilken bruger den skal logge ind som, af imagets OS-distribution. For de distributioner, den kender — debian, ubuntu, centos, rocky, almalinux (eller alma), fedora, rhel (eller redhat), amazonlinux (eller amzn), arch, freebsd, alpine — er det nok at angive os_distro som en af disse værdier, og den bruger er den, portalen viser som SSH-login, og den, en konsoladgangskode sættes på.

For alt andet kan den ikke gætte, og den forsøger ikke. At bede om en konsoladgangskode på et sådant Linux-image afvises blankt, ikke nedgraderet:

cannot determine the default user for this image; omit the console password or use an SSH key

Fortæl den det, så forsvinder afvisningen. Sæt login-brugeren til den konto, dit image rent faktisk opretter:

fm CLI

# Ved oprettelsen
fm compute image create --name my-nixos --file nixos.qcow2 \
  --os-distro nixos --default-user nixos

# Eller bagefter, på et image du allerede har uploadet
fm compute image update <image-id> --default-user nixos

# Send en tom værdi for at lade platformen bestemme igen
fm compute image update <image-id> --default-user ''

Terraform

resource "frostmoln_image" "nixos" {
  name         = "my-nixos"
  source_file  = "nixos.qcow2"
  disk_format  = "qcow2"
  os_distro    = "nixos"
  default_user = "nixos"
}

I portalen er det feltet Login-bruger på upload-formularen og under Rediger for et image, du allerede har.

I modsætning til os_distro kan denne ændres på stedet — et image, der har brug for det, kan rettes uden at blive uploadet på ny, og i Terraform erstatter den ikke ressourcen.

Et par ting, der er værd at vide:

• Lad den stå tom for en distribution, platformen kender. Det er en tilsidesættelse, ikke et påkrævet felt, og en tom værdi betyder "udled det af os_distro".
• Det skal være en konto, imaget allerede opretter. At sætte en konsoladgangskode opretter ikke brugeren; det sætter en adgangskode på en bruger, som cloud-init forventer at finde. Angiver du en, der ikke findes, får du en instans, hvis adgangskode ikke virker, uden at der siges noget ved starten.
• En konsoladgangskode sættes aldrig på root. Imaget accepterer root som login-bruger, og portalen viser den, men en start, der sætter en konsoladgangskode, afvises. Brug en SSH-nøgle til et image, hvis eneste konto er root.
• Et Windows-image tager aldrig en konsoladgangskode, uanset hvad der står her. Platformen udleder Administrator til visning og afviser adgangskoden alene ud fra os_type eller os_distro — det ændrer ikke noget at angive en login-bruger.
• Små bogstaver, tak, når der skal sættes en konsoladgangskode. Den accepterede form er op til 32 tegn, der begynder med et ASCII-bogstav eller _, og som indeholder ASCII-bogstaver, cifre, - og _. Blandede store og små bogstaver accepteres på imaget, så et Windows-image kan angive Administrator, men konsoladgangskode-vejen tager kun et Linux-brugernavn med små bogstaver og afviser i stedet for i stilhed at gøre det, du skrev, til små bogstaver.

Når en import mislykkes

En mislykket import efterlader ikke imaget i en fejltilstand. Den sætter imaget tilbage til queued — den samme status, som et image, der aldrig blev uploadet, har — og registrerer et separat importFailed-flag. Den skelnen har betydning, hvis du skriver din egen polling: poll efter active ELLER importFailed, aldrig efter active alene, ellers venter dit script for evigt på en mislykket import.

Både portalen og fm compute image get viser det (Import mislykkedes / en advarselslinje) sammen med årsagen, når platformen kan fastslå en:

• Filen indeholder et andet diskimage — en qcow2, der er eksporteret inde fra en anden qcow2. Det fejler på nøjagtig samme måde at uploade den samme fil igen. Eksportér gæstens disk fra hypervisoren som et almindeligt qcow2- eller raw-image, og upload det i stedet.
• Filen bruger en funktion, der ikke kan konverteres — en backing-fil eller kryptering. Flad den ud til ét ukrypteret image (qemu-img convert), og upload det.
• Filen har ikke det format, du angav — tjek, hvad den i virkeligheden er (qemu-img info fortæller dig det), sæt det matchende diskformat på imaget, og upload det så igen.
• Konverteringen mislykkedes — som regel en ufuldstændig upload eller et beskadiget image. Kontrollér, at filen kan åbnes lokalt, og upload den så igen.
• Platformen kunne ikke fastslå en årsag — kontakt support, og oplys imagets ID. Det er usandsynligt, at det hjælper at uploade den samme fil igen.

Poller du selv API'et, hedder årsagen importFailureReason på imaget, og dens værdi er en af nestedFormat, unsupportedFeature, declaredFormat, conversionFailed eller unknown. Der kan når som helst komme nye koder til — behandl en ukendt kode nøjagtigt som unknown.

Årsagen bliver liggende på imaget, så den er der stadig efter en genindlæsning eller dagen efter.

Det tager et par sekunder, før en fejl viser sig, og det er med vilje. Platformen erfarer, at en import mislykkedes, en anelse før den erfarer hvorfor, og den offentliggør ingen af delene, før begge er klar — så du aldrig får vist "importen mislykkedes" uden forklaring og med det ubrugelige råd om at uploade filen igen. I op til et minut ser imaget derfor nøjagtigt ud som et, ingen har uploadet til: queued, intet importFailed. Bliv ved med at polle. I det sjældne tilfælde, hvor platformen slet ikke kunne fastslå en årsag, får du fejlen uden en.

Ikke alle afvisninger når hertil. En fil, der ikke er et gyldigt qcow2- eller raw-diskimage, en der angiver en backing-fil eller er krypteret, og en hvis udvidede størrelse overstiger loftet på 35 GiB, afvises alle med det samme, med en 400 og en besked, der angiver årsagen — importen går aldrig i gang, og der registreres intet importFailed. importFailed betyder, at filen bestod de kontroller og derefter fejlede, mens den blev konverteret eller lagret.

Uanset hvad forbliver imaget i Afventer upload, og du kan uploade en rettet fil ind i den samme post.

Fakturering

Egne images faktureres pr. GB-måned på imagets logiske (udvidede) størrelse i decimale GB, så længe imaget findes — prissat som et volumen-snapshot. Den størrelse, der vises i portalen, er den, du betaler for. Sletter du et image, stopper opkrævningen.

Priserne kommer fra platformens priskatalog og vises i portalen; denne vejledning angiver ingen beløb. Se Fakturering.

Begrænsninger

• Kun qcow2 og raw, containerformat bare.
• 35 GiB uploadet / 35 GiB udvidet pr. image; 10 images / 376 GB pr. tenant som standard. Hvor mange uploads der må være undervejs samtidig, er også begrænset.
• Images er private for din tenant — det er ikke muligt at dele et image med en anden tenant. Inde i tenanten er de ikke fortrolige: alle, der kan starte en instans, kan læse hele filsystemet.
• Ingen download eller eksport — et uploadet image kan ikke hentes ud igen som en fil. Gem din egen kopi af alt, du kan få brug for igen.
• Det er ikke muligt at oprette et eget image ud fra et snapshot af en kørende instans; upload diskimaget i stedet.

Relateret

• Compute / Instanser · Kvoter og fakturering
• fm CLI · Terraform-provider