0 - en to nb-NO translation catalogue (426 entries)

en: Preseeding
nb-NO: Forhåndsutfylling

en: Monitoring
nb-NO: Monitorering

en: Virtualization
nb-NO: Virtualisering

en: Advanced Administration
nb-NO: Avansert administrasjon

en: This chapter revisits some aspects we already described, with a different perspective: instead of installing one single computer, we will study mass-deployment systems; instead of creating RAID or LVM volumes at install time, we'll learn to do it by hand so we can later revise our initial choices. Finally, we will discuss monitoring tools and virtualization techniques. As a consequence, this chapter is more particularly targeting professional administrators, and focuses somewhat less on individuals responsible for their home network.
nb-NO: Dette kapittelet tar opp igjen noen aspekter vi allerede har beskrevet, med et annet perspektiv: I stedet for å installere en enkelt datamaskin, vil vi studere masseutrullingssystemer; i stedet for å sette opp RAID eller LVM under installasjonen, vil vi lære å gjøre det for hånd, slik at vi senere kan endre våre første valg. Til slutt vil vi diskutere monitoreringsverktøy og virtualiseringsteknikker. Som en konsekvens, er dette kapitlet mest rettet mot profesjonelle administratorer, og fokuserer litt mindre på personer med ansvar for sine hjemmenettverk.

en: RAID and LVM
nb-NO: RAID og LVM

en: <primary>volume</primary><secondary>logical volume</secondary>
nb-NO: <primary>volum</primary><secondary>logisk volum</secondary>

en: <primary>volume</primary><secondary>raid volume</secondary>
nb-NO: <primary>volum</primary><secondary>raidvolum</secondary>

en: <primary>filesystem</primary><secondary>redundancy</secondary>
nb-NO: <primary>filsystem</primary><secondary>redundans</secondary>

en: RAID and LVM are both techniques to abstract the mounted volumes from their physical counterparts (actual hard-disk drives or partitions thereof); the former ensures the security and availability of the data in case of hardware failure by introducing redundancy, the latter makes volume management more flexible and independent of the actual size of the underlying disks. In both cases, the system ends up with new block devices, which can be used to create filesystems or swap space, without necessarily having them mapped to one physical disk. RAID and LVM come from quite different backgrounds, but their functionality can overlap somewhat, which is why they are often mentioned together.
nb-NO: RAID og LVM er begge teknikker til abstraksjon av de monterte volumene fra sine fysiske motstykker (faktiske harddisker eller partisjoner); den første sørger for data-sikkerhet og tilgjengelighet i tilfelle maskinvarefeil ved å innføre redundans. Sistnevnte gjør volumadministrasjon mer fleksibel og uavhengig av den faktiske størrelsen på de underliggende diskene. I begge tilfeller ender systemet opp med nye blokk-enheter, som kan brukes til å lage filsystemer eller vekselminnefiler, uten nødvendigvis å ha dem direktekoblet til en fysisk disk. RAID og LVM har veldig forskjellig bakgrunn, men siden funksjonaliteten kan overlappe noe, er de derfor ofte omtalt sammen.

en: <emphasis>PERSPECTIVE</emphasis> Btrfs combines LVM and RAID
nb-NO: <emphasis>PERSPEKTIV</emphasis> Btrfs kombinerer LVM og RAID

en: Among the noteworthy features are the ability to take a snapshot of a filesystem tree at any point in time. This snapshot copy doesn't initially use any disk space, the data only being duplicated when one of the copies is modified. The filesystem also handles transparent compression of files, and checksums ensure the integrity of all stored data.
nb-NO: Blant funksjonene verdt å legge merke til, er muligheten til på ethvert tidspunkt å ta et øyeblikksbilde av et filsystemtre. Denne øyeblikksbilde-kopien vil i utgangspunktet ikke bruke diskplass, data blir bare duplisert når en av kopiene blir endret. Filsystemet håndterer også gjennomsiktig komprimering av filer, og sjekksummer sikrer integriteten til alle lagrede data.

en: <primary>filesystem</primary><secondary>snapshot</secondary>
nb-NO: <primary>filsystem</primary><secondary>øyeblikksbilde</secondary>

en: In both the RAID and LVM cases, the kernel provides a block device file, similar to the ones corresponding to a hard disk drive or a partition. When an application, or another part of the kernel, requires access to a block of such a device, the appropriate subsystem routes the block to the relevant physical layer. Depending on the configuration, this block can be stored on one or several physical disks, and its physical location may not be directly correlated to the location of the block in the logical device.
nb-NO: Både for RAID og LVM gir kjernen en blokk-enhetsfil, lik dem som refererer til en harddisk eller en partisjon. Når et program, eller en annen del av kjernen, krever tilgang til en blokk på en slik enhet, dirigerer det aktuelle delsystem blokken til det aktuelle fysiske laget. Avhengig av oppsettet, kan denne blokken lagres på en eller flere fysiske disker, og det trenger ikke være sammenheng mellom den fysiske plasseringen og plassering av blokken i den logiske enheten.

en: Software RAID
nb-NO: Programvare RAID

en: <primary>RAID</primary><secondary>Software RAID</secondary>
nb-NO: <primary>RAID</primary><secondary>Programvare-RAID</secondary>

en: <primary>Redundant Array of Independent Disks</primary><see>RAID</see>
nb-NO: <primary>Redundant matrise av uavhengige disker</primary><see>RAID</see>

en: RAID means <emphasis>Redundant Array of Independent Disks</emphasis>. The goal of this system is to prevent data loss and ensure availability in case of hard disk failure. The general principle is quite simple: data are stored on several physical disks instead of only one, with a configurable level of redundancy. Depending on this amount of redundancy, and even in the event of an unexpected disk failure, data can be losslessly reconstructed from the remaining disks.
nb-NO: RAID betyr <emphasis>Redundant Array of Independent Disks</emphasis>, dvs. redundant rekke av uavhengige disker. Målet med dette systemet er å hindre datatap og sørge for tilgjengelighet ved feil på harddisken. Det generelle prinsippet er ganske enkelt: Data er lagret på flere fysiske disker i stedet for bare én med oppsatt grad av redundans. Avhengig av denne redundansmengden, og selv om det skjer en uventet diskfeil, kan data rekonstrueres uten tap fra de gjenværende diskene.

en: <emphasis>CULTURE</emphasis> <foreignphrase>Independent</foreignphrase> or <foreignphrase>inexpensive</foreignphrase>?
nb-NO: <emphasis>KULTUR</emphasis> <foreignphrase>Uavhengig</foreignphrase> eller <foreignphrase>billig</foreignphrase>?

en: The I in RAID initially stood for <emphasis>inexpensive</emphasis>, because RAID allowed a drastic increase in data safety without requiring investing in expensive high-end disks. Probably due to image concerns, however, it is now more customarily considered to stand for <emphasis>independent</emphasis>, which doesn't have the unsavory flavor of cheapness.
nb-NO: I-en i RAID sto opprinnelig for <emphasis>inexpensive</emphasis> (billig), fordi RAID tillot en drastisk økning i datasikkerhet uten å kreve investering i dyre høykvalitetsdisker. Sannsynligvis på grunn av hvordan det oppfattes, er det imidlertid nå en mer vanlig å si at det står for <emphasis>independent</emphasis> (uavhengig), som ikke gir det uønskede inntrykket av å være en ren kostnadsbesparelse.

en: <primary>RAID</primary><secondary>Hardware RAID</secondary>
nb-NO: <primary>RAID</primary><secondary>Maskinvare-RAID</secondary>

en: RAID can be implemented either by dedicated hardware (RAID modules integrated into SCSI or SATA controller cards) or by software abstraction (the kernel). Whether hardware or software, a RAID system with enough redundancy can transparently stay operational when a disk fails; the upper layers of the stack (applications) can even keep accessing the data in spite of the failure. Of course, this “degraded mode” can have an impact on performance, and redundancy is reduced, so a further disk failure can lead to data loss. In practice, therefore, one will strive to only stay in this degraded mode for as long as it takes to replace the failed disk. Once the new disk is in place, the RAID system can reconstruct the required data so as to return to a safe mode. The applications won't notice anything, apart from potentially reduced access speed, while the array is in degraded mode or during the reconstruction phase.
nb-NO: RAID kan implementeres enten ved øremerket maskinvare (RAID-moduler integrert i SCSI eller SATA-kontrollerkort), eller ved bruk av programvare-abstraksjoner (kjernen). Uansett om det er gjort i maskinvare eller programvare, kan et RAID-system, med nok redundans, fortsette å fungere når en disk feiler uten at brukeren oppdager problemer; de øvre lag av stabelen (applikasjoner) kan til og med fortsette å bruke dataene tross feilen. En slik «degradert modus» kan selvfølgelig ha en innvirkning på ytelsen, og redundansen er redusert, slik at en ytterligere diskfeil kan føre til tap av data. I praksis vil en derfor bestrebe seg på å bli værende med denne reduserte driften bare så lenge som det tar å erstatte den ødelagte disken. Så snart den nye disken er på plass, kan RAID-systemet rekonstruere de nødvendige data, og gå tilbake til en sikker modus. Programmene vil ikke merke noe, bortsett fra en potensielt redusert tilgangshastighet, mens området er i redusert drift, eller under rekonstruksjonsfasen.

en: When RAID is implemented by hardware, its configuration generally happens within the BIOS setup tool, and the kernel will consider a RAID array as a single disk, which will work as a standard physical disk, although the device name may be different (depending on the driver).
nb-NO: Når RAID implementeres i maskinvare, skjer oppsettet vanligvis i oppsettsverktøy i BIOS, og kjernen vil se på et RAID-sett som en enkelt disk, som vil virke som en standard fysisk disk, selv om navnet på enheten kan være forskjellig (avhengig av driveren).

en: We only focus on software RAID in this book.
nb-NO: Vi fokuserer bare på programvare-RAID i denne boken.

en: Different RAID Levels
nb-NO: Ulike RAID-nivåer

en: <primary>RAID</primary><secondary>level</secondary>
nb-NO: <primary>RAID</primary><secondary>nivå</secondary>

en: RAID is actually not a single system, but a range of systems identified by their levels; the levels differ by their layout and the amount of redundancy they provide. The more redundant, the more failure-proof, since the system will be able to keep working with more failed disks. The counterpart is that the usable space shrinks for a given set of disks; seen the other way, more disks will be needed to store a given amount of data.
nb-NO: RAID er faktisk ikke et enkelt system, men et spekter av systemer som identifiseres av sine nivåer. Nivåene skiller seg ved sin utforming og mengden av redundans de gir. Jo mer redundans, jo mer feilsikkert, siden systemet vil være i stand til å fortsette arbeidet med flere disker som feiler. Ulempen er at plassen som kan brukes, krymper for et gitt sett med disker, eller med andre ord; flere disker vil være nødvendig for å lagre en gitt mengde data.

en: Linear RAID
nb-NO: Lineært RAID

en: Even though the kernel's RAID subsystem allows creating “linear RAID”, this is not proper RAID, since this setup doesn't involve any redundancy. The kernel merely aggregates several disks end-to-end and provides the resulting aggregated volume as one virtual disk (one block device). That is about its only function. This setup is rarely used by itself (see later for the exceptions), especially since the lack of redundancy means that one disk failing makes the whole aggregate, and therefore all the data, unavailable.
nb-NO: Selv om kjernens RAID-delsystem kan lage «lineært RAID», er dette egentlig ikke en ekte RAID, siden dette oppsettet ikke gir redundans. Kjernen samler bare flere disker etter hverandre, og resulterer i et samlet volum som en virtuell disk (en blokkenhet). Det er omtrent dens eneste funksjon. Dette oppsettet brukes sjelden i seg selv (se senere for unntak), spesielt siden mangelen på redundans betyr at om en disk svikter, så feiler det samlede volumet, og gjør alle data utilgjengelige.

en: This level doesn't provide any redundancy either, but disks aren't simply stuck on end one after another: they are divided in <emphasis>stripes</emphasis>, and the blocks on the virtual device are stored on stripes on alternating physical disks. In a two-disk RAID-0 setup, for instance, even-numbered blocks of the virtual device will be stored on the first physical disk, while odd-numbered blocks will end up on the second physical disk.
nb-NO: Dette nivået gir heller ikke redundans, men diskene blir ikke lagt sammen ende mot ende: De blir delt i <emphasis>striper</emphasis>, og blokkene på den virtuelle enheten er lagret på striper på alternerende fysiske disker. I et to-disk RAID-0 oppsett, for eksempel, vil partallsblokker på den virtuelle enheten bli lagret på den første fysiske disken, mens oddetallsblokker vil komme på den andre fysiske disken.

en: This system doesn't aim at increasing reliability, since (as in the linear case) the availability of all the data is jeopardized as soon as one disk fails, but at increasing performance: during sequential access to large amounts of contiguous data, the kernel will be able to read from both disks (or write to them) in parallel, which increases the data transfer rate. The disks are utilized entirely by the RAID device, so they should have the same size not to lose performance.
nb-NO: Dette systemet har ikke som mål å øke påliteligheten, siden tilgjengeligheten (som i det lineære tilfellet) til alle data er i fare så snart en disk svikter, men å øke ytelsen: Under sekvensiell tilgang til store mengder sammenhengende data, vil kjernen være i stand til å lese fra begge disker (eller skrive til dem) parallelt, noe som øker hastigheten på dataoverføringen. Diskene brukes helt ut av RAID-enheten, så de bør ha samme størrelse for ikke å miste ytelsen.

en: RAID-0 use is shrinking, its niche being filled by LVM (see later).
nb-NO: RAID-0 -bruken minker, og nisjen blir nå oppfylt av LVM (videre beskrevet).

en: This level, also known as “RAID mirroring”, is both the simplest and the most widely used setup. In its standard form, it uses two physical disks of the same size, and provides a logical volume of the same size again. Data are stored identically on both disks, hence the “mirror” nickname. When one disk fails, the data is still available on the other. For really critical data, RAID-1 can of course be set up on more than two disks, with a direct impact on the ratio of hardware cost versus available payload space.
nb-NO: Dette nivået, også kjent som "RAID-speiling", er både det enkleste og det mest brukte oppsettet. I standardformen bruker den to fysiske disker av samme størrelse, og gir et tilsvarende logisk volum av samme størrelse. Data er lagret identisk på begge disker, derav kallenavnet «speiling». Når en disk svikter, er dataene fremdeles tilgjengelig på den andre. For virkelig kritiske data, kan RAID-1 selvsagt settes opp på mer enn to disker, med direkte konsekvenser for forholdet mellom maskinvarekostnader opp mot tilgjengelig plass for nyttelast.

en: <emphasis>NOTE</emphasis> Disks and cluster sizes
nb-NO: <emphasis>MERK</emphasis> Disk- og klyngestørrelser

en: If two disks of different sizes are set up in a mirror, the bigger one will not be fully used, since it will contain the same data as the smallest one and nothing more. The useful available space provided by a RAID-1 volume therefore matches the size of the smallest disk in the array. This still holds for RAID volumes with a higher RAID level, even though redundancy is stored differently.
nb-NO: Hvis to disker av forskjellige størrelse er satt opp i et speil, vil ikke den største bli brukt fullt ut, siden den vil inneholde de samme dataene som den minste og ingenting mer. Den brukbare tilgjengelige plassen levert av et RAID-1-volum er dermed størrelsen på den minste disken i rekken. Dette gjelder også for RAID-volumer med høyere RAID-nivå, selv om redundansen er fordelt på en annen måte.

en: It is therefore important, when setting up RAID arrays (except for RAID-0 and “linear RAID”), to only assemble disks of identical, or very close, sizes, to avoid wasting resources.
nb-NO: Det er derfor viktig når du setter opp RAID-sett (unntatt for RAID-0 og «lineær RAID»), å bare sette sammen disker av identiske eller svært like størrelser, for å unngå å sløse med ressurser.

en: <emphasis>NOTE</emphasis> Spare disks
nb-NO: <emphasis>MERK</emphasis> Reservedisker

en: <primary>spare disk</primary>
nb-NO: <primary>reservedisk</primary>

en: RAID levels that include redundancy allow assigning more disks than required to an array. The extra disks are used as spares when one of the main disks fails. For instance, in a mirror of two disks plus one spare, if one of the first two disks fails, the kernel will automatically (and immediately) reconstruct the mirror using the spare disk, so that redundancy stays assured after the reconstruction time. This can be used as another kind of safeguard for critical data.
nb-NO: RAID-nivåer som inkluderer redundans tillater tilordning av flere disker enn det som kreves til et sett. De ekstra diskene blir brukt som reservedisker når en av hoveddiskene svikter. For eksempel, i et speil som består av to disker pluss en i reserve; dersom en av de to første diskene svikter, vil kjernen automatisk (og umiddelbart) rekonstruere speilet ved hjelp av reservedisken, slik at redundansen forblir sikret etter gjenoppbyggingstidspunktet. Dette kan brukes som en annen form for ekstra sikkerhet for kritiske data.

en: One would be forgiven for wondering how this is better than simply mirroring on three disks to start with. The advantage of the “spare disk” configuration is that the spare disk can be shared across several RAID volumes. For instance, one can have three mirrored volumes, with redundancy assured even in the event of one disk failure, with only seven disks (three pairs, plus one shared spare), instead of the nine disks that would be required by three triplets.
nb-NO: Det er forståelig hvis du undrer deg på hvordan dette er bedre enn å ganske enkelt bare speile på tre disker. Fordelen med «reservedisk»-oppsettet er at en ekstra disk kan deles på tvers av flere RAID-volumer. For eksempel kan man ha tre speilende volumer, med redundans sikret også når en disk svikter med bare syv disker (tre par, pluss en felles i reserve), i stedet for de ni diskene som ville være nødvendig med tre sett med tre disker.

en: This RAID level, although expensive (since only half of the physical storage space, at best, is useful), is widely used in practice. It is simple to understand, and it allows very simple backups: since both disks have identical contents, one of them can be temporarily extracted with no impact on the working system. Read performance is often increased since the kernel can read half of the data on each disk in parallel, while write performance isn't too severely degraded. In case of a RAID-1 array of N disks, the data stays available even with N-1 disk failures.
nb-NO: Dette RAID-nivået, selv om det er dyrere (da bare halvparten av den fysiske lagringsplassen, i beste fall, er i bruk), er mye brukt i praksis. Det er enkelt å forstå, og det gjør det svært enkle å ta sikkerhetskopi: Siden begge diskene har identisk innhold, kan en av dem bli midlertidig tatt ut uten noen innvirkning på systemet ellers. Leseytelsen er ofte økt siden kjernen kan lese halvparten av dataene på hver disk parallelt, mens skriveytelsen ikke er altfor alvorlig svekket. I tilfelle med et RAID-sett med N-disker, forblir data tilgjengelig selv med N-1 diskfeil.

en: <primary>backup</primary>
nb-NO: <primary>sikkerhetskopi</primary>

en: RAID systems are not backup mechanisms. While RAID increases the redundancy - and therefore the availability of a system - and protects against disk failures, backups are done to protect data from being altered, deleted, getting corrupted, etc., and to be able to restore them if necessary. To demonstrate this: If you remove one or all files by accident, a RAID will mirror this change, but it will not provide the means to restore the file(s). So while there is clearly an overlap, they are not the same and should be used in conjunction with each other.
nb-NO: RAID-systemer er ikke sikkerhetskopieringsmekanismer. Selv om RAID øker redundanser (og dermed et systems tilgjengelig, og beskytter litt mot diskhavari) er det nødvendig med sikkerhetskopiering for å beskytte data fra endring, sletting, skade, osv. for å kunne gjenopprette hvis nødvendig. Eksempelvis: Hvis man fjerner én eller alle filene ved et uhell, vil RAID speile denne endringen, men ikke tilby en måte å gjenopprette filen(e). Dermed er det kun noen sammenfallende kvaliteter i anvendelsen, de er ikke like og bør brukes sammen.

en: This RAID level, not widely used, uses N disks to store useful data, and an extra disk to store redundancy information. If that disk fails, the system can reconstruct its contents from the other N. If one of the N data disks fails, the remaining N-1 combined with the “parity” disk contain enough information to reconstruct the required data.
nb-NO: Dette RAID-nivået, ikke mye brukt, bruker N plater til å lagre nyttige data, og en ekstra disk til å lagre redundanssinformasjon. Hvis den disken svikter, kan systemet rekonstruere innholdet fra de andre N. Hvis en av de N datadiskene svikter, inneholder den gjenværende N-1 kombinert med «paritets»-disken nok informasjon til å rekonstruere de nødvendige dataene.

en: <primary>RAID</primary><secondary>parity</secondary>
nb-NO: <primary>RAID</primary><secondary>paritet</secondary>

en: RAID-4 isn't too expensive since it only involves a one-in-N increase in costs and has no noticeable impact on read performance, but writes are slowed down. Furthermore, since a write to any of the N disks also involves a write to the parity disk, the latter sees many more writes than the former, and its lifespan can shorten dramatically as a consequence. Data on a RAID-4 array is safe only up to one failed disk (of the N+1).
nb-NO: RAID-4 er ikke for dyrt siden det kun omfatter en en-av-N økning i kostnader, og har ingen merkbar innvirkning på leseytelsen, men skriving går langsommere. Videre, siden skriving til hvilket som helst av de N platene også omfatter skriving til paritetsdisken, ser sistnevnte mange flere skriveoperasjoner enn førstnevnte, og paritetsdiskens levetid kan som konsekvens bli dramatisk kortere. Data på et RAID-4-sett er bare trygg med en feilet disk (av de N + 1).

en: RAID-5 addresses the asymmetry issue of RAID-4: parity blocks are spread over all of the N+1 disks, with no single disk having a particular role.
nb-NO: RAID-5 løser asymmetriutfordringen til RAID-4: Paritetsblokker er spredt over alle N + 1 disker, uten at en enkeltdisk har en bestemt rolle.

en: Read and write performance are identical to RAID-4. Here again, the system stays functional with up to one failed disk (of the N+1), but no more.
nb-NO: Lese- og skrivehastighet er den samme som for RAID-4. Her igjen forblir systemet funksjonelt med opp til en disk som feiler (av de N+1), men ikke flere.

en: RAID-6 can be considered an extension of RAID-5, where each series of N blocks involves two redundancy blocks, and each such series of N+2 blocks is spread over N+2 disks.
nb-NO: RAID-6 kan betraktes som en forlengelse av RAID-5, der hver serie med N blokker involverer to reserveblokker, og hver slik serie med N+2 blokker er spredt over N+2 disker.

en: This RAID level is slightly more expensive than the previous two, but it brings some extra safety since up to two drives (of the N+2) can fail without compromising data availability. The counterpart is that write operations now involve writing one data block and two redundancy blocks, which makes them even slower.
nb-NO: Dette RAID-nivået er litt dyrere enn de to foregående, men det bringer litt ekstra sikkerhet siden opptil to disker (av N+2) kan svikte uten at det går ut over datatilgjengeligheten. Ulempen er at skriveoperasjoner nå innebærer å skrive ut på en datablokk og to reserveblokker, noe som gjør dem enda tregere.

en: This isn't strictly speaking, a RAID level, but a stacking of two RAID groupings. Starting from 2×N disks, one first sets them up by pairs into N RAID-1 volumes; these N volumes are then aggregated into one, either by “linear RAID” or (increasingly) by LVM. This last case goes farther than pure RAID, but there is no problem with that.
nb-NO: Dette er strengt tatt ikke et RAID-nivå, men en samling av to RAID-grupperinger. En starter med 2×N disker og setter dem først opp som par i N RAID-1-volumer; Disse N volumene blir så samlet til ett, enten ved «lineært RAID», eller (i økende grad) med LVM. Dette siste tilfellet gjør mer enn et rent RAID-oppsett, men det er ikke et problem.

en: RAID-1+0 can survive multiple disk failures: up to N in the 2×N array described above, provided that at least one disk keeps working in each of the RAID-1 pairs.
nb-NO: RAID-1+0 kan overleve flere diskfeil: opp til N i 2xN-settet som er beskrevet ovenfor, forutsatt at minst en disk fortsetter å virke i hver av RAID-1-parene.

en: <emphasis>GOING FURTHER</emphasis> RAID-10
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> RAID-10

en: RAID-10 is generally considered a synonym of RAID-1+0, but a Linux specificity makes it actually a generalization. This setup allows a system where each block is stored on two different disks, even with an odd number of disks, the copies being spread out along a configurable model.
nb-NO: RAID-10 er generelt ansett som synonym for RAID-1+0, men en Linux-spesialitet gjør det faktisk til en generalisering. Dette oppsettet gjør det mulig med et system der hver blokk er lagret på to ulike disker, selv med et oddetall disker, der kopiene blir spredt ut i en modell som kan settes opp.

en: Performances will vary depending on the chosen repartition model and redundancy level, and of the workload of the logical volume.
nb-NO: Ytelsen vil variere avhengig av valgt repartisjonsmodell og redundansnivå, og av arbeidsmengden til det logiske volumet.

en: Obviously, the RAID level will be chosen according to the constraints and requirements of each application. Note that a single computer can have several distinct RAID arrays with different configurations.
nb-NO: Selvfølgelig må RAID-nivået velges ut fra begrensningene og kravene til hvert program. Merk at en enkelt datamaskin kan ha flere ulike RAID-sett med forskjellige oppsett.

en: Setting up RAID
nb-NO: Oppsett av RAID

en: <primary>RAID</primary><secondary>create</secondary>
nb-NO: <primary>RAID</primary><secondary>opprette</secondary>

en: Setting up RAID volumes requires the <emphasis role="pkg">mdadm</emphasis> package; it provides the <command>mdadm</command> command, which allows creating and manipulating RAID arrays, as well as scripts and tools integrating it to the rest of the system, including the monitoring system.
nb-NO: Oppsett av RAID-volumer krever <emphasis role="pkg">mdadm</emphasis>-pakken; den leverer <command>mdadm</command>-kommandoen, som gjør det mulig å lage og håndtere RAID-tabeller, samt prosedyrer og verktøy som integrerer den i resten av systemet, inkludert monitoreringssystemet.

en: Our example will be a server with a number of disks, some of which are already used, the rest being available to setup RAID. We initially have the following disks and partitions:
nb-NO: Vårt eksempel vil være en tjener med en rekke disker, der noen er allerede brukt, og resten er tilgjengelig til å sette opp RAID. Vi har i utgangspunktet følgende disker og partisjoner:

en: the <filename>sdb</filename> disk, 4 GB, is entirely available;
nb-NO: <filename>sdb</filename>-disken, 4 GB, er tilgjengelig i sin helhet;

en: the <filename>sdc</filename> disk, 4 GB, is also entirely available;
nb-NO: <filename>sdc</filename>-disken, 4 GB, er også helt tilgjengelig;

en: on the <filename>sdd</filename> disk, only partition <filename>sdd2</filename> (about 4 GB) is available;
nb-NO: På <filename>sdd</filename>-disken, er bare partisjonen <filename>sdd2</filename> (rundt 4 GB) tilgjengelig;

en: finally, a <filename>sde</filename> disk, still 4 GB, entirely available.
nb-NO: til slutt er en <filename>sde</filename>-disk, også på 4 GB, fullt ut tilgjengelig.

en: <emphasis>NOTE</emphasis> Identifying existing RAID volumes
nb-NO: <emphasis>MERK</emphasis> Identifisere eksisterende RAID-volumer

en: The <filename>/proc/mdstat</filename> file lists existing volumes and their states. When creating a new RAID volume, care should be taken not to name it the same as an existing volume.
nb-NO: Filen <filename>/proc/mdstat</filename> lister eksisterende volumer og tilstanden deres. Når du oppretter et nytt RAID-volum, bør man være forsiktig for å ikke gi det samme navnet som på et eksisterende volum.

en: We're going to use these physical elements to build two volumes, one RAID-0 and one mirror (RAID-1). Let's start with the RAID-0 volume:
nb-NO: Vi kommer til å bruke disse fysiske elementene for å bygge to volumer, et RAID-0 og et speil (RAID-1). La oss starte med RAID-0-volumet:

en: The <command>mdadm --create</command> command requires several parameters: the name of the volume to create (<filename>/dev/md*</filename>, with MD standing for <foreignphrase>Multiple Device</foreignphrase>), the RAID level, the number of disks (which is compulsory despite being mostly meaningful only with RAID-1 and above), and the physical drives to use. Once the device is created, we can use it like we'd use a normal partition, create a filesystem on it, mount that filesystem, and so on. Note that our creation of a RAID-0 volume on <filename>md0</filename> is nothing but coincidence, and the numbering of the array doesn't need to be correlated to the chosen amount of redundancy. It is also possible to create named RAID arrays, by giving <command>mdadm</command> parameters such as <filename>/dev/md/linear</filename> instead of <filename>/dev/md0</filename>.
nb-NO: Kommandoen <command>mdadm --create</command> krever flere parametre: Navnet på volumet som skal opprettes (<filename>/dev/md*</filename>, der MD står for <foreignphrase>Multiple Device</foreignphrase>), RAID-nivået, antall disker (som er obligatorisk til tross for at det er mest meningsfylt bare med RAID-1 og over), og de fysiske enhetene som skal brukes. Når enheten er opprettet, kan vi bruke den som vi ville brukt en vanlig partisjon, opprette et filsystem på den, montere dette filsystemet, og så videre. Vær oppmerksom på at vår oppretting av et RAID-0-volum på <filename>md0</filename> kun er tilfeldig, og at sekvensen av numrene i tabellen ikke trenger å være samsvare med valgt redundansnivå. Det er også mulig å lage navngitte RAID-array, ved å gi <command>mdadm</command> et parameter ala <filename>/dev/md/linear</filename> istedenfor <filename>/dev/md0</filename>.

en: Creation of a RAID-1 follows a similar fashion, the differences only being noticeable after the creation:
nb-NO: Opprettelse av et RAID-1 gjøres på lignende måte, forskjellene blir bare merkbare etter opprettelsen:

en: <emphasis>TIP</emphasis> RAID, disks and partitions
nb-NO: <emphasis>TIPS</emphasis> RAID, disker og partisjoner

en: A few remarks are in order. First, <command>mdadm</command> notices that the physical elements have different sizes; since this implies that some space will be lost on the bigger element, a confirmation is required.
nb-NO: Noen få merknader er på sin plass. Først, <command>mdadm</command> merker at de fysiske elementene har forskjellige størrelser; siden dette innebærer at noe plass går tapt på de større elementene, kreves en bekreftelse.

en: More importantly, note the state of the mirror. The normal state of a RAID mirror is that both disks have exactly the same contents. However, nothing guarantees this is the case when the volume is first created. The RAID subsystem will therefore provide that guarantee itself, and there will be a synchronization phase as soon as the RAID device is created. After some time (the exact amount will depend on the actual size of the disks…), the RAID array switches to the “active” or “clean” state. Note that during this reconstruction phase, the mirror is in a degraded mode, and redundancy isn't assured. A disk failing during that risk window could lead to losing all the data. Large amounts of critical data, however, are rarely stored on a freshly created RAID array before its initial synchronization. Note that even in degraded mode, the <filename>/dev/md1</filename> is usable, and a filesystem can be created on it, as well as some data copied on it.
nb-NO: Enda viktigere er det å merke tilstanden til speilet. Normal tilstand for et RAID-speil er at begge diskene har nøyaktig samme innhold. Men ingenting garanterer at dette er tilfelle når volumet blir opprettet. RAID-delsystem vil derfor sikre denne garantien selv, og det vil være en synkroniseringsfase i det RAID-enheten er opprettet. Etter en tid (den nøyaktige tiden vil avhenge av den faktiske størrelsen på diskene ...), skifter RAID-tabellen til «aktiv» eller «ren» tilstand. Legg merke til at i løpet av denne gjenoppbyggingsfasen, er speilet i en degradert modus, og reservekapasitet er ikke sikret. En disk som svikter på dette trinnet kan føre til at alle data mistes. Store mengder av viktige data er imidlertid sjelden lagret på en nyopprettet RAID før den første synkroniseringen. Legg merke til at selv i degradert modus, vil <filename>/dev/md1</filename> kunne brukes, og et filsystem kan opprettes på den, og data kan kopieres inn.

en: <emphasis>TIP</emphasis> Starting a mirror in degraded mode
nb-NO: <emphasis>TIPS</emphasis> Oppstart av speil i degradert modus

en: Sometimes two disks are not immediately available when one wants to start a RAID-1 mirror, for instance because one of the disks one plans to include is already used to store the data one wants to move to the array. In such circumstances, it is possible to deliberately create a degraded RAID-1 array by passing <filename>missing</filename> instead of a device file as one of the arguments to <command>mdadm</command>. Once the data have been copied to the “mirror”, the old disk can be added to the array. A synchronization will then take place, giving us the redundancy that was wanted in the first place.
nb-NO: Noen ganger er to disker ikke umiddelbart tilgjengelig når man ønsker å starte et RAID-1-speil, for eksempel fordi en av diskene som planlegges inkludert, allerede er brukt til å lagre dataene man ønsker å flytte til settet. I slike tilfeller er det mulig å med vilje opprette et degradert RAID-1-sett ved å sende <filename>missing</filename> i stedet for en enhetsfil som ett av argumentene til <command>mdadm</command>. Når dataene er kopiert til «speilet», kan den gamle disken legges til settet. Deretter vil det finne sted en synkronisering, noe som gir oss den reservekapasitet som var ønsket i første omgang.

en: <emphasis>TIP</emphasis> Setting up a mirror without synchronization
nb-NO: <emphasis>TIPS</emphasis> Oppsett av et speil uten synkronisering

en: RAID-1 volumes are often created to be used as a new disk, often considered blank. The actual initial contents of the disk is therefore not very relevant, since one only needs to know that the data written after the creation of the volume, in particular the filesystem, can be accessed later.
nb-NO: RAID-1-volumer opprettes oftest for å brukes som en ny disk, som antas å være blank. Det faktiske og opprinnelige innholdet på disken er dermed ikke så relevant, siden man bare trenger å vite at dataene som er skrevet etter at volumet og spesielt filsystemet er opprettet, kan nås senere.

en: One might therefore wonder about the point of synchronizing both disks at creation time. Why care whether the contents are identical on zones of the volume that we know will only be read after we have written to them?
nb-NO: Man kan derfor lure på om poenget med å synkronisere begge diskene ved tidpunktet for opprettelsen er god. Hvorfor bry seg om innholdet er identisk på soner i volumet som vi vet kun vil leses etter at vi har skrevet til dem?

en: Fortunately, this synchronization phase can be avoided by passing the <literal>--assume-clean</literal> option to <command>mdadm</command>. However, this option can lead to surprises in cases where the initial data will be read (for instance if a filesystem is already present on the physical disks), which is why it isn't enabled by default.
nb-NO: Heldigvis kan denne synkroniseringsfasen unngås ved å sende inn <literal>--assume-clean</literal>-valget til <command>mdadm</command>. Imidlertid kan dette alternativet gi overraskelser i tilfeller der de opprinnelige dataene leses (for eksempel hvis et filsystem allerede er til stede på de fysiske diskene). Dette er grunnen til at valget ikke er aktivert som standard.

en: <primary>RAID</primary><secondary>failing</secondary>
nb-NO: <primary>RAID</primary><secondary>feiler</secondary>

en: Now let's see what happens when one of the elements of the RAID-1 array fails. <command>mdadm</command>, in particular its <literal>--fail</literal> option, allows simulating such a disk failure:
nb-NO: La oss nå se hva som skjer når et av elementene i RAID-1-settet svikter. <command>mdadm</command>, spesielt <literal>--fail</literal>-valget tillater å simulere en slik diskfeiling:

en: The contents of the volume are still accessible (and, if it is mounted, the applications don't notice a thing), but the data safety isn't assured anymore: should the <filename>sdd</filename> disk fail in turn, the data would be lost. We want to avoid that risk, so we'll replace the failed disk with a new one, <filename>sdf</filename>:
nb-NO: Innholdet i volumet er fortsatt tilgjengelig (og, hvis det er montert, legger ikke programmene merke til noen ting), men datasikkerheten er ikke trygg lenger: Skulle <filename>sdd</filename>-disken i sin tur svikte, vil data gå tapt. Vi ønsker å unngå denne risikoen, så vi erstatter den ødelagte disken med en ny, <filename>sdf</filename>:

en: Here again, the kernel automatically triggers a reconstruction phase during which the volume, although still accessible, is in a degraded mode. Once the reconstruction is over, the RAID array is back to a normal state. One can then tell the system that the <filename>sde</filename> disk is about to be removed from the array, so as to end up with a classical RAID mirror on two disks:
nb-NO: Her utløser kjernen som vanlig automatisk en rekonstruksjonsfase der volumet fortsatt er tilgjengelig, men i en degradert modus. Når gjenoppbyggingen er over, er RAID-settet tilbake i normal tilstand. Man kan da si til systemet at <filename>sde</filename>-disken er i ferd med å bli fjernet fra settet, for å ende opp med et klassisk RAID-speil med to disker:

en: From then on, the drive can be physically removed when the server is next switched off, or even hot-removed when the hardware configuration allows hot-swap. Such configurations include some SCSI controllers, most SATA disks, and external drives operating on USB or Firewire.
nb-NO: Etter dette kan disken fysisk fjernes når tjenermaskinen er slått av neste gang, eller til og med fjernes under kjøring hvis maskinvareoppsettet tillater det. Slike oppsett inkluderer noen SCSI-kontrollere, de fleste SATA-disker, og eksterne harddisker tilkoblet via USB eller Firewire.

en: Backing up the Configuration
nb-NO: Sikkerhetskopi av oppsettet

en: Backing up the configuration is therefore important, if only for reference. The standard way to do it is by editing the <filename>/etc/mdadm/mdadm.conf</filename> file, an example of which is listed here:
nb-NO: Å sikkerhetskopiere oppsettet er derfor viktig, om enn bare som referanse. Den vanlige måten å gjøre det på er å endre på <filename>/etc/mdadm/mdadm.conf</filename>-filen, et eksempel på det er listet her:

en: <command>mdadm</command> configuration file
nb-NO: <command>mdadm</command>-oppsettsfil

en: One of the most useful details is the <literal>DEVICE</literal> option, which lists the devices where the system will automatically look for components of RAID volumes at start-up time. In our example, we replaced the default value, <literal>partitions containers</literal>, with an explicit list of device files, since we chose to use entire disks and not only partitions, for some volumes.
nb-NO: En av de mest nyttige detaljer er <literal>DEVICE</literal>-valget, som viser enhetene som systemet automatisk vil undersøke for å se etter deler av RAID-volumer ved oppstarts. I vårt eksempel erstattet vi standardverdien, <literal>partitions containers</literal>, med en eksplisitt liste over enhetsfiler, siden vi valgte å bruke hele disker, og ikke bare partisjoner for noen volumer.

en: The last two lines in our example are those allowing the kernel to safely pick which volume number to assign to which array. The metadata stored on the disks themselves are enough to re-assemble the volumes, but not to determine the volume number (and the matching <filename>/dev/md*</filename> device name).
nb-NO: De to siste linjene i vårt eksempel er de som tillater kjernen trygt å velge hvilke volumnummer som skal tilordnes hvilket sett. Metadataene som er lagret på selve diskene er nok til å sette volumene sammen igjen, men ikke for å bestemme volumnummeret (og det matchende <filename>/dev/md*</filename>-enhetsnavn).

en: Fortunately, these lines can be generated automatically:
nb-NO: Heldigvis kan disse linjene generes automatisk:

en: The contents of these last two lines doesn't depend on the list of disks included in the volume. It is therefore not necessary to regenerate these lines when replacing a failed disk with a new one. On the other hand, care must be taken to update the file when creating or deleting a RAID array.
nb-NO: Innholdet i disse to siste linjene avhenger ikke av listen over disker som inngår i volumet. Det er derfor ikke nødvendig å lage disse linjene på nytt når du bytter ut en feilet disk med en ny. På den annen side må man sørge for å oppdatere filen når en oppretter eller sletter et RAID-sett.

en: LVM, the <emphasis>Logical Volume Manager</emphasis>, is another approach to abstracting logical volumes from their physical supports, which focuses on increasing flexibility rather than increasing reliability. LVM allows changing a logical volume transparently as far as the applications are concerned; for instance, it is possible to add new disks, migrate the data to them, and remove the old disks, without unmounting the volume.
nb-NO: LVM, <emphasis>Logical Volume Manager</emphasis> ( logisk volumhåndtering), er en annen tilnærming for å abstrahere logiske volumer fra sin fysiske forankring, som fokuserer på økt fleksibilitet i stedet for økt pålitelighet. LVM lar deg endre et logisk volum transparent så langt programmene angår; for eksempel er det mulig å legge til nye disker, overføre dataene til dem, og fjerne gamle disker, uten at volumet avmonteres.

en: LVM Concepts
nb-NO: LVM-konsepter

en: <primary>Physical Volume</primary><see>PV</see>
nb-NO: <primary>Fysisk volum (Physical Volume)</primary><see>PV</see>

en: This flexibility is attained by a level of abstraction involving three concepts.
nb-NO: Denne fleksibilitet oppnås med et abstraksjonsnivå som involverer tre konsepter.

en: First, the PV (<emphasis>Physical Volume</emphasis>) is the entity closest to the hardware: it can be partitions on a disk, or a full disk, or even any other block device (including, for instance, a RAID array). Note that when a physical element is set up to be a PV for LVM, it should only be accessed via LVM, otherwise the system will get confused.
nb-NO: Først, PV (<emphasis>Physical Volume</emphasis>, fysisk volum) er enheten nærmest maskinvaren: Det kan være partisjoner på en disk, en hel disk, eller til og med en annen blokkenhet (inkludert, for eksempel, et RAID-sett). Merk at når et fysisk element er satt opp til å bli en PV for LVM, skal den kun være tilgjengelige via LVM, ellers vil systemet bli forvirret.

en: <primary>Volume Group</primary><see>VG</see>
nb-NO: <primary>Volumgruppe</primary><see>VG</see>

en: A number of PVs can be clustered in a VG (<emphasis>Volume Group</emphasis>), which can be compared to disks both virtual and extensible. VGs are abstract, and don't appear in a device file in the <filename>/dev</filename> hierarchy, so there is no risk of using them directly.
nb-NO: Et antall PV-er kan samles i en VG (<emphasis>Volume Group</emphasis>, volumgruppe), som kan sammenlignes med både virtuelle og utvidbare disker. VG-er er abstrakte, og dukker ikke opp som en enhetsfil i <filename>/dev</filename>-hierarkiet, så det er ingen risiko for å bruke dem direkte.

en: <primary>Logical Volume</primary><see>LV</see>
nb-NO: <primary>Logisk volum</primary><see>LV</see>

en: The third kind of object is the LV (<emphasis>Logical Volume</emphasis>), which is a chunk of a VG; if we keep the VG-as-disk analogy, the LV compares to a partition. The LV appears as a block device with an entry in <filename>/dev</filename>, and it can be used as any other physical partition can be (most commonly, to host a filesystem or swap space).
nb-NO: Den tredje typen objekt er LV (<emphasis>Logical Volume</emphasis>, logisk volum), som er en del av en VG; hvis vi holder på analogien VG-som-disk, kan LV sammenlignes med en partisjon. LV-en fremstår som en blokkenhet med en oppføring i <filename>/dev</filename>, og den kan brukes som en hvilken som helst annen fysisk partisjon (som oftest, som en vert for et filsystem eller et vekselminne).

en: The important thing is that the splitting of a VG into LVs is entirely independent of its physical components (the PVs). A VG with only a single physical component (a disk for instance) can be split into a dozen logical volumes; similarly, a VG can use several physical disks and appear as a single large logical volume. The only constraint, obviously, is that the total size allocated to LVs can't be bigger than the total capacity of the PVs in the volume group.
nb-NO: Det viktige er at splittingen av en VG til LV-er er helt uavhengig av dens fysiske komponenter (PV-ene). En VG med bare en enkelt fysisk komponent (en disk for eksempel) kan deles opp i et dusin logiske volumer; på samme måte kan en VG bruke flere fysiske disker, og fremstå som et eneste stort logisk volum. Den eneste begrensningen, selvsagt, er at den totale størrelsen tildelt LV-er kan ikke være større enn den totale kapasiteten til PV-ene i volumgruppen.

en: It often makes sense, however, to have some kind of homogeneity among the physical components of a VG, and to split the VG into logical volumes that will have similar usage patterns. For instance, if the available hardware includes fast disks and slower disks, the fast ones could be clustered into one VG and the slower ones into another; chunks of the first one can then be assigned to applications requiring fast data access, while the second one will be kept for less demanding tasks.
nb-NO: Det er imidlertid ofte fornuftig å ha en viss form for homogenitet blant de fysiske komponentene i en VG, og dele VG-en i logiske volumer som vil ha lignende brukermønstre. For eksempel, hvis tilgjengelig maskinvare inkluderer raske og tregere disker, kan de raske bli gruppert i en VG, og de tregere i en annen; deler av den første kan deretter bli tildelt til applikasjoner som krever rask tilgang til data, mens den andre kan beholdes til mindre krevende oppgaver.

en: In any case, keep in mind that an LV isn't particularly attached to any one PV. It is possible to influence where the data from an LV are physically stored, but this possibility isn't required for day-to-day use. On the contrary: when the set of physical components of a VG evolves, the physical storage locations corresponding to a particular LV can be migrated across disks (while staying within the PVs assigned to the VG, of course).
nb-NO: I alle fall, husk at en LV ikke er spesielt knyttet til en bestemt PV. Det er mulig å påvirke hvor data fra en LV fysisk er lagret, men å bruk denne muligheten er ikke nødvendig til daglig. Tvert imot: Ettersom settet med fysiske komponenter i en VG utvikler seg, kan de fysiske lagringsstedene som tilsvarer en bestemt LV, spres over disker (mens den selvfølgelig blir værende innenfor PV-er tildelt VG-en).

en: Setting up LVM
nb-NO: Oppsett av LVM

en: <primary>LVM</primary><secondary>setup</secondary>
nb-NO: <primary>LVM</primary><secondary>oppsett</secondary>

en: Let us now follow, step by step, the process of setting up LVM for a typical use case: we want to simplify a complex storage situation. Such a situation usually happens after some long and convoluted history of accumulated temporary measures. For the purposes of illustration, we'll consider a server where the storage needs have changed over time, ending up in a maze of available partitions split over several partially used disks. In more concrete terms, the following partitions are available:
nb-NO: La oss nå følge prosessen, steg for steg, med å sette opp LVM i et typisk brukstilfelle: Vi ønsker å forenkle en kompleks lagringssituasjon. En slik situasjon oppstår vanligvis etter en lang og innfløkt historie med akkumulerte midlertidige tiltak. For illustrasjonsformål vil vi vurdere en tjenermaskin der lagringsbehovene har endret seg over tid, og endte opp i en labyrint av tilgjengelige partisjoner fordelt over flere delvis brukte disker. Mer konkret er følgende partisjoner tilgjengelige:

en: on the <filename>sdb</filename> disk, a <filename>sdb2</filename> partition, 4 GB;
nb-NO: på <filename>sdb</filename>-disken, en <filename>sdb2</filename>-partisjon, 4 GB;

en: on the <filename>sdc</filename> disk, a <filename>sdc3</filename> partition, 3 GB;
nb-NO: på <filename>sdc</filename>-disken, en <filename>sdc3</filename>-partisjon, 3 GB;

en: the <filename>sdd</filename> disk, 4 GB, is fully available;
nb-NO: <filename>sdd</filename>-disken, 4 GB, hele er tilgjengelig;

en: on the <filename>sdf</filename> disk, a <filename>sdf1</filename> partition, 4 GB; and a <filename>sdf2</filename> partition, 5 GB.
nb-NO: på <filename>sdf</filename>-disken, en <filename>sdf1</filename>-partisjon, 4 GB; og en <filename>sdf2</filename>-partisjon, 5 GB.

en: In addition, let's assume that disks <filename>sdb</filename> and <filename>sdf</filename> are faster than the other two.
nb-NO: I tillegg, la oss anta at diskene <filename>sdb</filename> og <filename>sdf</filename> er raskere enn de to andre.

en: Our goal is to set up three logical volumes for three different applications: a file server requiring 5 GB of storage space, a database (1 GB) and some space for back-ups (12 GB). The first two need good performance, but back-ups are less critical in terms of access speed. All these constraints prevent the use of partitions on their own; using LVM can abstract the physical size of the devices, so the only limit is the total available space.
nb-NO: Målet vårt er å sette opp tre logiske volumer for tre ulike programmer: En filtjener som krever 5 GB lagringsplass, en database (1 GB), og noe plass for sikkerhetskopiering (12 GB). De to første trenger god ytelse, men sikkerhetskopiering er mindre kritisk med tanke på tilgangshastighet. Alle disse begrensninger forhindrer bruk av partisjoner på egen hånd; å bruke LVM kan samle den fysiske størrelsen på enhetene, slik at den totale tilgjengelige plassen er den eneste begrensningen.

en: The required tools are in the <emphasis role="pkg">lvm2</emphasis> package and its dependencies. When they're installed, setting up LVM takes three steps, matching the three levels of concepts.
nb-NO: Verktøyene som kreves er i <emphasis role="pkg">lvm2</emphasis>-pakken og dens avhengigheter. Når de er installert, skal det tre trinn til for å sette opp LVM som svarer til de tre konseptnivåene.

en: First, we prepare the physical volumes using <command>pvcreate</command>:
nb-NO: Først gjør vi klare de fysiske volumene ved å bruke <command>pvcreate</command>:

en: So far, so good; note that a PV can be set up on a full disk as well as on individual partitions of it. As shown above, the <command>pvdisplay</command> command lists the existing PVs, with two possible output formats.
nb-NO: Alt bra så langt. Vær oppmerksom på at en PV kan settes opp på en hel disk, samt på individuelle partisjoner på disken. Kommandoen <command>pvdisplay</command>, som vist ovenfor, lister eksisterende PV-er, med to mulige utdataformater.

en: Now let's assemble these physical elements into VGs using <command>vgcreate</command>. We'll gather only PVs from the fast disks into a <filename>vg_critical</filename> VG; the other VG, <filename>vg_normal</filename>, will also include slower elements.
nb-NO: Deretter setter vi sammen disse fysiske elementer til VG-er ved å bruke <command>vgcreate</command>. Vi samler kun raske PV-er i VG-en <filename>vg_critical</filename>. Den andre VG-en, <filename>vg_normal</filename>, vil inneholde også langsommere enheter.

en: Here again, commands are rather straightforward (and <command>vgdisplay</command> proposes two output formats). Note that it is quite possible to use two partitions of the same physical disk into two different VGs. Note also that we used a <filename>vg_</filename> prefix to name our VGs, but it is nothing more than a convention.
nb-NO: Her ser vi igjen at kommandoene er ganske greie (og <command>vgdisplay</command> foreslår to utdataformater). Merk at det er fullt mulig å bruke to partisjoner på samme fysiske disk i to forskjellige VG-er. Merk også at vi navnga våre VG-er med <filename>vg_</filename>-forstavelse. Dette er ikke noe mer enn en konvensjon.

en: We now have two “virtual disks”, sized about 8 GB and 12 GB respectively. Let's now carve them up into “virtual partitions” (LVs). This involves the <command>lvcreate</command> command, and a slightly more complex syntax:
nb-NO: Vi har nå to «virtuelle disker», med størrelse henholdsvis ca. 8 GB og 12 GB. La oss nå dele dem opp i «virtuelle partisjoner» (LV-er). Dette innebærer bruk av kommandoen <command>lvcreate</command>, og en litt mer komplisert syntaks:

en: Two parameters are required when creating logical volumes; they must be passed to the <command>lvcreate</command> as options. The name of the LV to be created is specified with the <literal>-n</literal> option, and its size is generally given using the <literal>-L</literal> option. We also need to tell the command what VG to operate on, of course, hence the last parameter on the command line.
nb-NO: To parameter er nødvendig når du oppretter logiske volumer; de må sendes til <command>lvcreate</command> som tilvalg. Navnet på LV som skal opprettes er angitt med alternativet <literal>-n</literal>, og dens størrelse er generelt gitt ved å bruke <literal>-L</literal>-alternativet. Vi trenger også, selvfølgelig, å fortelle kommandoen hvilken VG som skal brukes, derav det siste parameteret på kommandolinjen.

en: <emphasis>GOING FURTHER</emphasis> <command>lvcreate</command> options
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> <command>lvcreate</command>-valgene

en: The <command>lvcreate</command> command has several options to allow tweaking how the LV is created.
nb-NO: Kommandoen <command>lvcreate</command> har flere alternativer for å tilpasse hvordan LV-en opprettes.

en: Let's first describe the <literal>-l</literal> option, with which the LV's size can be given as a number of blocks (as opposed to the “human” units we used above). These blocks (called PEs, <emphasis>physical extents</emphasis>, in LVM terms) are contiguous units of storage space in PVs, and they can't be split across LVs. When one wants to define storage space for an LV with some precision, for instance to use the full available space, the <literal>-l</literal> option will probably be preferred over <literal>-L</literal>.
nb-NO: La oss først beskrive <literal>-l</literal>-valget, der LVs størrelse kan gis som et antall blokker (i motsetning til de «menneskelige» enheter vi brukte ovenfor). Disse blokkene (kalt PES, <emphasis>physical extents</emphasis> (fysiske omfang), i LVM-termer) er sammenhengende enheter med lagringsplass i PV-er, og de kan ikke deles på tvers av LV-er. Når man ønsker å definere lagringsplass for en LV med noe presisjon, for eksempel å bruke hele den tilgjengelige plassen, vil <literal>-l</literal>-valget trolig foretrekkes fremfor <literal>-L</literal>.

en: It is also possible to hint at the physical location of an LV, so that its extents are stored on a particular PV (while staying within the ones assigned to the VG, of course). Since we know that <filename>sdb</filename> is faster than <filename>sdf</filename>, we may want to store the <filename>lv_base</filename> there if we want to give an advantage to the database server compared to the file server. The command line becomes: <command>lvcreate -n lv_base -L 1G vg_critical /dev/sdb2</command>. Note that this command can fail if the PV doesn't have enough free extents. In our example, we would probably have to create <filename>lv_base</filename> before <filename>lv_files</filename> to avoid this situation – or free up some space on <filename>sdb2</filename> with the <command>pvmove</command> command.
nb-NO: Det er også mulig å hinte om fysisk plassering for en LV, slik at dens omfang lagres på en bestemt PV (mens du selvfølgelig er innenfor den som er tildelt VG-en). Siden vi vet at <filename>sdb</filename> er raskere enn <filename>sdf</filename>, kan det hende vi ønsker å lagre <filename>lv_base</filename> der hvis vi ønsker å gi en fordel til databasetjeneren i forhold til filtjeneren. Da blir kommandolinjen: <command>lvcreate -n lv_base -L 1G vg_critical /dev/sdb2</command>. Merk at denne kommandoen kan feile hvis PV-en ikke har nok ledig plass. I vårt eksempel ville vi trolig måtte lage <filename>lv_base</filename> før <filename>lv_files</filename> for å unngå denne situasjonen - eller frigjøre litt plass på <filename>sdb2</filename> med kommandoen <command>pvmove</command>.

en: Logical volumes, once created, end up as block device files in <filename>/dev/mapper/</filename>:
nb-NO: Logiske volumer, når de er opprettet, ender opp som blokkenhetsfiler i <filename>/dev/mapper/</filename>:

en: <primary>device</primary><secondary>block</secondary>
nb-NO: <primary>enhet</primary><secondary>blokk</secondary>

en: <emphasis>NOTE</emphasis> Auto-detecting LVM volumes
nb-NO: <emphasis>MERK</emphasis> Finn LVM-volumer automatisk

en: <primary>service</primary><secondary><filename>lvm2-activation.service</filename></secondary>
nb-NO: <primary>tjeneste</primary><secondary><filename>lvm2-activation.service</filename></secondary>

en: When the computer boots, the <filename>lvm2-activation</filename> systemd service unit executes <command>vgchange -aay</command> to “activate” the volume groups: it scans the available devices; those that have been initialized as physical volumes for LVM are registered into the LVM subsystem, those that belong to volume groups are assembled, and the relevant logical volumes are started and made available. There is therefore no need to edit configuration files when creating or modifying LVM volumes.
nb-NO: Når datamaskinen starter, vil systemd-tjenesteenheten <filename>lvm2-activation</filename> kjøre <command>vgchange -aay</command> for å «aktivisere» volumgrupper. Denne søker igjennom de tilgjengelige enhetene; de som har blitt initialisert som fysiske volumer for LVM, blir registrert i LVM-delsystemet, de som tilhører volumgrupper monteres, og de aktuelle logiske volumer startes og gjøres tilgjengelige. Det er derfor ikke nødvendig å endre på oppsettsfiler når du oppretter eller endrer LVM-volumer.

en: Note, however, that the layout of the LVM elements (physical and logical volumes, and volume groups) is backed up in <filename>/etc/lvm/backup</filename>, which can be useful in case of a problem (or just to sneak a peek under the hood).
nb-NO: Merk imidlertid at utformingen av LVM-elementer (fysiske og logiske volumer, og volumgrupper) sikkerhetskopieres i <filename>/etc/lvm/backup</filename>, som er nyttig hvis det oppstår et problem (eller bare for å titte under panseret).

en: To make things easier, convenience symbolic links are also created in directories matching the VGs:
nb-NO: For å gjøre ting enklere er praktiske og egnede symbolske lenker også opprettet i kataloger som samsvarer med VG-er:

en: The LVs can then be used exactly like standard partitions:
nb-NO: LV-ene kan deretter brukes akkurat som vanlige partisjoner:

en: From the applications' point of view, the myriad small partitions have now been abstracted into one large 12 GB volume, with a friendlier name.
nb-NO: Fra programmenes synspunkt har de utallige små partisjonene nå blitt abstrahert til ett stort 12 GB volum, med et hyggeligere navn.

en: LVM Over Time
nb-NO: LVM over tid

en: Even though the ability to aggregate partitions or physical disks is convenient, this is not the main advantage brought by LVM. The flexibility it brings is especially noticed as time passes, when needs evolve. In our example, let's assume that new large files must be stored, and that the LV dedicated to the file server is too small to contain them. Since we haven't used the whole space available in <filename>vg_critical</filename>, we can grow <filename>lv_files</filename>. For that purpose, we'll use the <command>lvresize</command> command, then <command>resize2fs</command> to adapt the filesystem accordingly:
nb-NO: Selv om muligheten til å samle sammen partisjoner eller fysiske disker er praktisk, er dette ikke den viktigste fordelen LVM gir oss. Fleksibiliteten den gir, merkes spesielt over tid, etter som behovene utvikler seg. I vårt eksempel, la oss anta at nye store filer må lagres, og at LV øremerket til filtjeneren er for liten til å romme dem. Siden vi ikke har brukt hele plassen i <filename>vg_critical</filename>, kan vi gjøre <filename>lv_files</filename> større. Til det formålet bruker vi kommandoen <command>lvresize</command>, deretter <command>resize2fs</command> for å tilpasse filsystemet tilsvarende:

en: <emphasis>CAUTION</emphasis> Resizing filesystems
nb-NO: <emphasis>VÆR VARSOM</emphasis> Endre størrelse på filsystemer

en: Not all filesystems can be resized online; resizing a volume can therefore require unmounting the filesystem first and remounting it afterwards. Of course, if one wants to shrink the space allocated to an LV, the filesystem must be shrunk first; the order is reversed when the resizing goes in the other direction: the logical volume must be grown before the filesystem on it. It is rather straightforward, since at no time must the filesystem size be larger than the block device where it resides (whether that device is a physical partition or a logical volume).
nb-NO: Ikke alle filsystemer kan endre størrelse mens de er i bruk; Å endre størrelse på et volum kan derfor kreve at filsystemet avmonteres først og monteres på nytt i etterkant. Naturligvis, hvis en ønsker å krympe plassen avsatt til en LV, må filsystemet krympes først;. Rekkefølgen reverseres når endring av størrelse går i motsatt retning: det logiske volumet må utvides før filsystemet det inneholder. Det er ganske enkelt, siden ikke på noe tidspunkt må filsystemets størrelse være større enn blokkenheten der den ligger (enten den enheten er en fysisk partisjon eller et logisk volum).

en: The ext3, ext4 and xfs filesystems can be grown online, without unmounting; shrinking requires an unmount. The reiserfs filesystem allows online resizing in both directions. The venerable ext2 allows neither, and always requires unmounting.
nb-NO: Filsystemene ext3, ext4 og xfs kan vokse mens de er i bruk, uten avmontering. Krymping krever avmontering. Reiserfs filsystem tillater endring av størrelse i begge retninger mens det er i bruk. Det ærverdige ext2 håndterer ingen av delene, og krever alltid avmontering.

en: We could proceed in a similar fashion to extend the volume hosting the database, only we've reached the VG's available space limit:
nb-NO: Vi kunne fortsette med på tilsvarende måte å utvide volumet som er vertskap for databasen, men vi har nådd VG-ens grense for tilgjengelig plass:

en: <emphasis>GOING FURTHER</emphasis> Advanced LVM
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Avansert LVM

en: LVM also caters for more advanced uses, where many details can be specified by hand. For instance, an administrator can tweak the size of the blocks that make up physical and logical volumes, as well as their physical layout. It is also possible to move blocks across PVs, for instance, to fine-tune performance or, in a more mundane way, to free a PV when one needs to extract the corresponding physical disk from the VG (whether to affect it to another VG or to remove it from LVM altogether). The manual pages describing the commands are generally clear and detailed. A good entry point is the <citerefentry><refentrytitle>lvm</refentrytitle> <manvolnum>8</manvolnum></citerefentry> manual page.
nb-NO: LVM åpner også for mer avansert bruk, der mange detaljer kan spesifiseres for hånd. For eksempel kan en administrator justere størrelsen på blokkene som utgjør fysiske og logiske volumer, samt deres fysiske utforminger. Det er også mulig å flytte blokker mellom PV-er, for eksempel, for å finjustere ytelsen, eller mer hverdagslig, å frigjøre en PV når man trenger å trekke ut den tilsvarende fysiske disken fra VG-en (om den skal kobles til en annen VG eller å fjernes helt fra LVM). Manualsidene som beskriver kommandoene er generelt klare og detaljerte. Et god inngangspunkt er manualsiden<citerefentry><refentrytitle>lvm</refentrytitle> <manvolnum>8</manvolnum></citerefentry>.

en: RAID or LVM?
nb-NO: RAID eller LVM?

en: RAID and LVM both bring indisputable advantages as soon as one leaves the simple case of a desktop computer with a single hard disk where the usage pattern doesn't change over time. However, RAID and LVM go in two different directions, with diverging goals, and it is legitimate to wonder which one should be adopted. The most appropriate answer will of course depend on current and foreseeable requirements.
nb-NO: Både RAID og LVM bringer udiskutable fordeler så snart man forlater det enkle tilfellet med en stasjonær datamaskin med en enkelt harddisk, der bruksmønster ikke endres over tid. Men RAID og LVM går i to forskjellige retninger, med divergerende mål, og det er legitimt å lure på hvilken som bør velges. Det mest hensiktsmessige svaret vil selvfølgelig avhenge av nåværende og forventede krav.

en: There are a few simple cases where the question doesn't really arise. If the requirement is to safeguard data against hardware failures, then obviously RAID will be set up on a redundant array of disks, since LVM doesn't really address this problem. If, on the other hand, the need is for a flexible storage scheme where the volumes are made independent of the physical layout of the disks, RAID doesn't help much and LVM will be the natural choice.
nb-NO: Det finnes noen enkle tilfeller hvor spørsmålet egentlig ikke oppstår. Hvis kravet er å sikre data mot maskinvarefeil, så vil åpenbart RAID bli satt opp med en romslig sett med disker, ettersom LVM ikke løser dette problemet. På den andre side, dersom det er behov for et fleksibelt lagringsopplegg der volumene lages uavhengig av den fysiske utformingen av diskene, bidrar ikke RAID med mye, og LVM vil være det naturlige valget.

en: <emphasis>NOTE</emphasis> If performance matters…
nb-NO: <emphasis>MERK</emphasis> Når ytelse teller…

en: <primary>Solid State Drives</primary><see>SSD</see>
nb-NO: <primary>DIsker uten bevegelige deler</primary><see>SSD</see>

en: If input/output speed is of the essence, especially in terms of access times, using LVM and/or RAID in one of the many combinations may have some impact on performances, and this may influence decisions as to which to pick. However, these differences in performance are really minor, and will only be measurable in a few use cases. If performance matters, the best gain to be obtained would be to use non-rotating storage media (<emphasis>solid-state drives</emphasis> or SSDs); their cost per megabyte is higher than that of standard hard disk drives, and their capacity is usually smaller, but they provide excellent performance for random accesses. If the usage pattern includes many input/output operations scattered all around the filesystem, for instance for databases where complex queries are routinely being run, then the advantage of running them on an SSD far outweigh whatever could be gained by picking LVM over RAID or the reverse. In these situations, the choice should be determined by other considerations than pure speed, since the performance aspect is most easily handled by using SSDs.
nb-NO: Hvis lese/skrive-hastigheten er vesentlig, spesielt når det gjelder aksesstid, kan det å bruke LVM og/eller RAID i en av de mange kombinasjonene ha en viss innvirkning på ytelsen, og dette kan ha betydning for hvilken som skal velges. Men disse ytelsesforskjellene er veldig små, og vil bare være målbare i noen brukstilfeller. Hvis ytelsen betyr noe, er det størst gevinst ved å bruke ikke-roterende lagringsmedier (<emphasis>solid-state drives</emphasis>, eller SSDs). Prisen pr. megabyte er høyere enn for standard harddisker og kapasiteten er vanligvis mindre, men de gir utmerket ytelse når det gjelder tilfeldig aksess. Hvis bruksmønster inneholder mange lese/skrive-operasjoner spredt rundt i filsystemet, for eksempel for databaser der komplekse spørringer utføres rutinemessig, så oppveier fordelen av å kjøre dem på en SSD langt hva som kan oppnås ved å velge LVM over RAID eller omvendt. I slike situasjoner bør valget bestemmes av andre hensyn enn ren fart, siden ytelsesaspektet lettest håndteres ved å bruke SSD.

en: The third notable use case is when one just wants to aggregate two disks into one volume, either for performance reasons or to have a single filesystem that is larger than any of the available disks. This case can be addressed both by a RAID-0 (or even linear-RAID) and by an LVM volume. When in this situation, and barring extra constraints (for instance, keeping in line with the rest of the computers if they only use RAID), the configuration of choice will often be LVM. The initial set up is barely more complex, and that slight increase in complexity more than makes up for the extra flexibility that LVM brings if the requirements change or if new disks need to be added.
nb-NO: Det tredje bemerkelsesverdige brukstilfellet er når man bare ønsker å samle to disker i ett volum, enten av ytelseshensyn, eller for å ha et enkelt filsystem som er større enn noen av de tilgjengelige diskene. Dette tilfellet kan adresseres både med en RAID-0 (eller til og med en lineær-RAID), og med et LVM-volum. Når du er i denne situasjonen, og ikke har øvrige begrensninger (for eksempel å måtte fungere likt med de andre datamaskinene hvis de bare bruker RAID), vil oppsettsvalget ofte være LVM. Første gangs oppsett er ikke spesielt mer komplekst, og den svake økning i kompleksitet mer enn gjør opp for LVMs ekstra fleksibilitet dersom kravene må endres, eller dersom nye disker må legges til.

en: Then of course, there is the really interesting use case, where the storage system needs to be made both resistant to hardware failure and flexible when it comes to volume allocation. Neither RAID nor LVM can address both requirements on their own; no matter, this is where we use both at the same time — or rather, one on top of the other. The scheme that has all but become a standard since RAID and LVM have reached maturity is to ensure data redundancy first by grouping disks in a small number of large RAID arrays, and to use these RAID arrays as LVM physical volumes; logical partitions will then be carved from these LVs for filesystems. The selling point of this setup is that when a disk fails, only a small number of RAID arrays will need to be reconstructed, thereby limiting the time spent by the administrator for recovery.
nb-NO: Så er det selvfølgelig det virkelig interessante brukseksempel, der lagringssystemet må gjøres både motstandsdyktig mot maskinvarefeil, og gi en fleksibel volumtildeling. Verken RAID eller LVM kan imøtekomme begge kravene på egen hånd. Uansett, det er her vi bruker begge samtidig - eller rettere sagt, den ene oppå den andre. Ordningen som har alt, men er blitt en standard siden RAID og LVM har nådd modenheten til å sikre datatallighet (dataredundans), først ved å gruppere disker i et lite antall store RAID-sett, og å bruke disse RAID-settene som LVM fysiske volumer. Logiske partisjoner vil da bli meislet ut fra disse LV-ene for filsystemer. Salgsargumentet med dette oppsettet er at når en disk svikter, vil bare et lite antall RAID-sett trenge rekonstruksjon, og dermed begrense tiden administrator bruker for gjenoppretting.

en: RAID-1 and LVM are combined to satisfy these constraints. The disks are attached to two different SATA controllers to optimize parallel access and reduce the risk of a simultaneous failure, and they therefore appear as <filename>sda</filename> and <filename>sdc</filename>. They are partitioned identically along the following scheme:
nb-NO: RAID-1 og LVM kombineres for å tilfredsstille disse begrensningene. Diskene er knyttet til to forskjellige SATA-kontrollere for å optimalisere parallell tilgang, og redusere risikoen for samtidig svikt, og de vises derfor som <filename>sda</filename> og <filename>sdc</filename>. De er partisjonert likt slik det vises under:

en: The first partitions of both disks are BIOS boot partitions.
nb-NO: De første partisjonene på begge diskene er BIOS-oppstartspartisjoner.

en: Once the VGs are created, they can be partitioned in a very flexible way. One must keep in mind that LVs created in <filename>vg_raid</filename> will be preserved even if one of the disks fails, which will not be the case for LVs created in <filename>vg_bulk</filename>; on the other hand, the latter will be allocated in parallel on both disks, which allows higher read or write speeds for large files.
nb-NO: Når VG-ene er opprettet, kan de svært fleksibelt deles opp. Man må huske på at LV-er opprettet i <filename>vg_raid</filename>, blir bevart selv om en av diskene svikter, noe som ikke vil være tilfelle for LV-er opprettet i <filename>vg_bulk</filename>. På den annen side vil de sistnevnte fordeles i parallell på begge disker, som tillater høyere lese- eller skrivehastigheter for store filer.

en: We will therefore create the <filename>lv_var</filename> and <filename>lv_home</filename> LVs on <filename>vg_raid</filename>, to host the matching filesystems; another large LV, <filename>lv_movies</filename>, will be used to host the definitive versions of movies after editing. The other VG will be split into a large <filename>lv_rushes</filename>, for data straight out of the digital video cameras, and a <filename>lv_tmp</filename> for temporary files. The location of the work area is a less straightforward choice to make: while good performance is needed for that volume, is it worth risking losing work if a disk fails during an editing session? Depending on the answer to that question, the relevant LV will be created on one VG or the other.
nb-NO: Vi lager derfor LV-ene <filename>lv_var</filename> og <filename>lv_home</filename> på <filename>vg_raid</filename> som vertskap for de tilsvarende filsystemene. En annen stor LV, <filename>lv_movies</filename>, skal brukes som vert for endelige versjoner av filmer etter redigering. Den andre VG-en vil bli delt inn i et stort <filename>lv_rushes</filename>, for data rett fra det digitale videokameraet, og et <filename>lv_tmp</filename> for midlertidige filer. Plasseringen av arbeidsområdet er et mindre enkelt valg å ta. Mens god ytelse er nødvendig for det volumet, er det verdt å risikere å miste arbeid hvis en disk svikter under redigeringsøkten? Avhengig av svaret på det spørsmålet, vil den aktuelle LV-en bli lagt til den ene VG-en, eller på den andre.

en: We now have both some redundancy for important data and much flexibility in how the available space is split across the applications.
nb-NO: Vi har nå både endel redundans for viktige data, og mye fleksibilitet i hvordan den tilgjengelige plassen er delt mellom programmene.

en: <emphasis>NOTE</emphasis> Why three RAID-1 volumes?
nb-NO: <emphasis>MERK</emphasis> Hvorfor tre RAID-1-volumer?

en: We could have set up one RAID-1 volume only, to serve as a physical volume for <filename>vg_raid</filename>. Why create three of them, then?
nb-NO: Vi kunne ha satt opp ett RAID-1-volum bare for å tjene som et fysisk volum for <filename>vg_raid</filename>. Hva er poenget med å lage tre av dem?

en: The rationale for the first split (<filename>md0</filename> vs. the others) is about data safety: data written to both elements of a RAID-1 mirror are exactly the same, and it is therefore possible to bypass the RAID layer and mount one of the disks directly. In case of a kernel bug, for instance, or if the LVM metadata become corrupted, it is still possible to boot a minimal system to access critical data such as the layout of disks in the RAID and LVM volumes; the metadata can then be reconstructed and the files can be accessed again, so that the system can be brought back to its nominal state.
nb-NO: Forklaringen på den første delingen (<filename>md0</filename> versus de andre) dreier seg om datasikkerhet. Data skrevet til begge elementer i et RAID-1-speil er nøyaktig de samme, og det er derfor mulig å gå rundt RAID-laget, og montere en av diskene direkte. I tilfelle av, for eksempel en kjernefeil, eller hvis LVM-metadata blir ødelagt, er det fortsatt mulig å starte opp et minimalt system for å få tilgang til viktige data som for eksempel utformingen av diskene i RAID-et og LVM-en. Metadataene kan så rekonstrueres, og filene kan igjen nås, slik at systemet kan bringes tilbake til sin nominelle tilstand.

en: <primary>virtualization</primary>
nb-NO: <primary>virtualisering</primary>

en: Virtualization is one of the most major advances in the recent years of computing. The term covers various abstractions and techniques simulating virtual computers with a variable degree of independence on the actual hardware. One physical server can then host several systems working at the same time and in isolation. Applications are many, and often derive from this isolation: test environments with varying configurations for instance, or separation of hosted services across different virtual machines for security.
nb-NO: Virtualisering er et av de viktigste fremskritt i de seneste årenes datautvikling. Begrepet omfatter ulike abstraksjoner og teknikker som simulerer virtuelle datamaskiner med varierende grad av uavhengighet på selve maskinvaren. En fysisk tjenermaskin kan så være vert for flere systemer som arbeider samtidig, og i isolasjon. Bruksområdene er mange, og utledes ofte fra denne isolasjonen: for eksempel testmiljøer med varierende oppsett, eller separasjon av vertsbaserte tjenester mellom ulike virtuelle maskiner for sikkerheten.

en: There are multiple virtualization solutions, each with its own pros and cons. This book will focus on Xen, LXC, and KVM, but other noteworthy implementations include the following:
nb-NO: Det er flere virtualiseringsløsninger, hver med sine egne fordeler og ulemper. Denne boken vil fokusere på Xen, LXC, og KVM, mens andre implementasjoner verdt å nevne er de følgende:

en: Bochs is another free virtual machine, but it only emulates the x86 architectures (i386 and amd64).
nb-NO: Bochs er en annen fritt tilgjengelig virtuell maskin, men den emulerer bare x86-arkitekturene (i386 og amd64).

en: <emphasis>HARDWARE</emphasis> Virtualization support
nb-NO: <emphasis>HARDWARE</emphasis> Virtualiseringsstøtte

en: Some computers might not have hardware virtualization support; when they do, it should be enabled in the BIOS.
nb-NO: Noen datamaskiner har kanskje ikke støtte for maskinvarevirtualisering. når det skjer, bør den aktiveres i BIOS.

en: To know if you have virtualization support enabled, you can check if the relevant flag is enabled with <command>grep</command>. If the following command for your processor returns some text, you already have virtualization support enabled:
nb-NO: Hvis du vil vite om du har aktivert virtualiseringsstøtte, kan du kontrollere om det relevante flagget er aktivert med <command>grep</command>. Hvis følgende kommando for prosessoren returnerer tekst, har du allerede virtualiseringsstøtte aktivert:

en: If that is not the case, you can access the BIOS of your system and check for entries like “Intel Virtualization Technology”/“Intel VT-x” or “SVM mode” (AMD) - usually to be found in the CPU configuration in the Advanced section.
nb-NO: Hvis det er ikke tilfelle kan du gå inn i BIOS på ditt system og lete etter oppføringer som «Intel Virtualization Technology»/«Intel VT-x» eller «SVM mode» (AMD) — vanligvis er disse å finne i prosessor-oppsett i den avanserte delen.

en: Xen <indexterm><primary>Xen</primary></indexterm> is a “paravirtualization” solution. It introduces a thin abstraction layer, called a “hypervisor”, between the hardware and the upper systems; this acts as a referee that controls access to hardware from the virtual machines. However, it only handles a few of the instructions, the rest is directly executed by the hardware on behalf of the systems. The main advantage is that performances are not degraded, and systems run close to native speed; the drawback is that the kernels of the operating systems one wishes to use on a Xen hypervisor need to be adapted to run on Xen.
nb-NO: Xen <indexterm><primary>Xen</primary></indexterm> er en «paravirtualiserings»-løsning. Den introduserer et tynt abstraksjonslag, kalt en «hypervisor», mellom maskinvaren og de øvre systemer; dette fungerer som en dommer som kontrollerer tilgangen til maskinvaren for de virtuelle maskinene, men den håndterer bare noen av instruksjonene, resten kjøres direkte av maskinvaren på vegne av systemene. Den største fordelen er at ytelsen ikke blir dårligere, og systemer kjører med nær sin normale hastighet; ulempen er at operativsystemkjernene man ønsker å bruke på en Xen-hypervisor, trenger tilpasning for å kjøre på Xen.

en: Let's spend some time on terms. The hypervisor is the lowest layer, which runs directly on the hardware, even below the kernel. This hypervisor can split the rest of the software across several <emphasis>domains</emphasis>, which can be seen as so many virtual machines. One of these domains (the first one that gets started) is known as <emphasis>dom0</emphasis>, and has a special role, since only this domain can control the hypervisor and the execution of other domains. These other domains are known as <emphasis>domU</emphasis>. In other words, and from a user point of view, the <emphasis>dom0</emphasis> matches the “host” of other virtualization systems, while a <emphasis>domU</emphasis> can be seen as a “guest”.
nb-NO: La oss bruke litt tid på terminologi. Hypervisoren er det nederste laget, som kjører direkte på maskinvaren, under kjernen. Denne hypervisoren kan dele resten av programvaren over flere <emphasis>domener</emphasis>, som kan sees på som like mange virtuelle maskiner. Et av disse domenene (den første som blir startet) er kjent som <emphasis>dom0</emphasis>, og har en spesiell rolle, siden bare dette domenet kan kontrollere hypervisor, og kjøring av andre domener. Disse andre domener kalles <emphasis>domU</emphasis>. Med andre ord, og fra et brukersynspunkt, tilsvarer <emphasis>dom0</emphasis> «verten» i andre visualiseringssystemer, mens en <emphasis>domU</emphasis> kan bli sett på som en «gjest».

en: <emphasis>CULTURE</emphasis> Xen and the various versions of Linux
nb-NO: <emphasis>KULTUR</emphasis> Xen og de ulike versjonene av Linux

en: Xen was initially developed as a set of patches that lived out of the official tree, and not integrated to the Linux kernel. At the same time, several upcoming virtualization systems (including KVM) required some generic virtualization-related functions to facilitate their integration, and the Linux kernel gained this set of functions (known as the <emphasis>paravirt_ops</emphasis> or <emphasis>pv_ops</emphasis> interface). Since the Xen patches were duplicating some of the functionality of this interface, they couldn't be accepted officially.
nb-NO: Xen ble opprinnelig utviklet som et sett endringer som eksisterte på utsiden av det offisielle treet, og som ikke ble integrert i Linux-kjernen. Samtidig krevde flere fremvoksende virtualiseringssystemer (inkludert KVM) noen generiske virtualiseringsrelaterte funksjoner for å lette integreringen sin, og Linux-kjernen fikk dette settet av funksjoner (kjent som <emphasis>paravirt_ops</emphasis>, eller <emphasis>pv_ops</emphasis>-grensesnittet). Ettersom Xen dupliserte noen av funksjonalitetene til dette grensesnittet, kunne de ikke bli offisielt akseptert.

en: Xensource, the company behind Xen, therefore had to port Xen to this new framework, so that the Xen patches could be merged into the official Linux kernel. That meant a lot of code rewrite, and although Xensource soon had a working version based on the paravirt_ops interface, the patches were only progressively merged into the official kernel. The merge was completed in Linux 3.0. <ulink type="block" url="https://wiki.xenproject.org/wiki/XenParavirtOps" />
nb-NO: XenSource, selskapet bak Xen, måtte derfor legge til Xen i dette nye rammeverket, slik at Xens rettelser kunne flettes inn i den offisielle Linux-kjernen. Det betydde mye omskriving av kode, og selv om XenSource snart hadde en fungerende versjon basert på paravirt_ops-grensesnittet, ble rettelsene bare gradvis fusjonert inn den offisielle kjernen. Flettingen ble ferdigstilt i Linux 3.0. <ulink type="block" url="http://wiki.xenproject.org/wiki/XenParavirtOps" />

en: Since <emphasis role="distribution">Jessie</emphasis> is based on version 3.16 of the Linux kernel, the standard <emphasis role="pkg">linux-image-686-pae</emphasis> and <emphasis role="pkg">linux-image-amd64</emphasis> packages include the necessary code, and the distribution-specific patching that was required for <emphasis role="distribution">Squeeze</emphasis> and earlier versions of Debian is no more. <ulink type="block" url="https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix" />
nb-NO: Ettersom <emphasis role="distribution">Jessie</emphasis> er basert på Linux-kjernens versjon 3.16, inkluderer standardpakkene <emphasis role="pkg">linux-image-686-pae</emphasis>, og <emphasis role="pkg">linux-image-amd64</emphasis> den nødvendige koden, og distribusjonsspesifikke endringer som trengs til <emphasis role="distribution">Squeeze</emphasis>, og tidligere versjoner av Debian trengs ikke lenger. <ulink type="block" url="https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix" />

en: <emphasis>CULTURE</emphasis> Xen and non-Linux kernels
nb-NO: <emphasis>KULTUR</emphasis> Xen og ikke-Linux kjerner

en: Xen requires modifications to all the operating systems one wants to run on it; not all kernels have the same level of maturity in this regard. Many are fully-functional, both as dom0 and domU: Linux 3.0 and later, NetBSD 4.0 and later, and OpenSolaris. Others only work as a domU. You can check the status of each operating system in the Xen wiki: <ulink type="block" url="https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen" /> <ulink type="block" url="https://wiki.xenproject.org/wiki/DomU_Support_for_Xen" />
nb-NO: Xen krever endringer i alle operativsystemer man ønsker å kjøre på den. Alle kjerner har ikke samme modenhetsnivå når det gjelder dette. Mange er fullt funksjonelle, både som Dom0 og DomU: Linux 3.0 og senere, NetBSD 4.0 og senere, og OpenSolaris. Andre funger bare som en DomU. Du kan sjekke status for hvert operativsystem i Xen-Wikien: <ulink type="block" url="https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen" /> <ulink type="block" url="https://wiki.xenproject.org/wiki/DomU_Support_for_Xen" />

en: However, if Xen can rely on the hardware functions dedicated to virtualization (which are only present in more recent processors), even non-modified operating systems can run as domU (including Windows).
nb-NO: Men hvis Xen kan stole på maskinvarefunksjonene øremerket til virtualisering (som bare er til stede i nyere prosessorer), kan til og med ikke-modifiserte operativsystemer kjøres som DomU (inkludert Windows).

en: <emphasis>NOTE</emphasis> Architectures compatible with Xen
nb-NO: <emphasis>MERK</emphasis> Xen-kompatible arkitekturer

en: Xen is currently only available for the i386, amd64, arm64 and armhf architectures.
nb-NO: Xen er foreløpig kun tilgjengelig for arkitekturene i386, amd64, arm64 og armhf.

en: Using Xen under Debian requires three components:
nb-NO: Å bruke Xen under Debian krever tre komponenter:

en: The i386 architecture also requires a standard library with the appropriate patches taking advantage of Xen; this is in the <emphasis role="pkg">libc6-xen</emphasis> package.
nb-NO: i386-arkitekturen krever også et standard bibliotek med de riktige oppdateringer som drar nytte av Xen; dette er i <emphasis role="pkg">libc6-xen</emphasis>-pakken.

en: Once these prerequisites are installed, the next step is to test the behavior of the dom0 by itself; this involves a reboot to the hypervisor and the Xen kernel. The system should boot in its standard fashion, with a few extra messages on the console during the early initialization steps.
nb-NO: Når disse nødvendighetene er installert, er neste skritt å teste hvordan Dom0 virker alene. Dette innebærer omstart for hypervisoren og Xen-kjernen. Systemet skal starte på vanlig måte, med noen ekstra meldinger på konsollen under de tidlige initialiseringstrinnene.

en: Now is the time to actually install useful systems on the domU systems, using the tools from <emphasis role="pkg">xen-tools</emphasis>. This package provides the <command>xen-create-image</command> command, which largely automates the task. The only mandatory parameter is <literal>--hostname</literal>, giving a name to the domU; other options are important, but they can be stored in the <filename>/etc/xen-tools/xen-tools.conf</filename> configuration file, and their absence from the command line doesn't trigger an error. It is therefore important to either check the contents of this file before creating images, or to use extra parameters in the <command>xen-create-image</command> invocation. Important parameters of note include the following:
nb-NO: Så er det på tide å installere nyttige systemer på DomU-systemene med verktøy fra <emphasis role="pkg">xen-tools</emphasis>. Denne pakken leverer <command>xen-create-image</command>-kommandoen, som i stor grad automatiserer oppgaven. Den eneste nødvendige parameteren er <literal>--hostname</literal>, som gir navn til DomU-en. Andre valg er viktige, men de kan lagres i oppsettsfilen <filename>/etc/xen-tools/xen-tools.conf</filename>, og fraværet deres fra kommandolinjen utløser ikke en feil. Det er derfor viktig å enten sjekke innholdet i denne filen før du oppretter bilder, eller å bruke ekstra parametre i bruken av <command>xen-create-image</command>. Viktige parametre omfatter de følgende:

en: <literal>--memory</literal>, to specify the amount of RAM dedicated to the newly created system;
nb-NO: <literal>--memory</literal>, for å spesifisere hvor mye RAM som er øremerket til det systemet som nettopp er laget;

en: <literal>--size</literal> and <literal>--swap</literal>, to define the size of the “virtual disks” available to the domU;
nb-NO: <literal>--size</literal> og <literal>--swap</literal>, for å definere størrelsen på de «virtuelle diskene» som er tilgjengelig for DomU-en;

en: <emphasis>GOING FURTHER</emphasis> Installing a non-Debian system in a domU
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Installasjon av ikke-Debian-system i DomU

en: In case of a non-Linux system, care should be taken to define the kernel the domU must use, using the <literal>--kernel</literal> option.
nb-NO: Med et ikke-Linux-system må en, ved hjelp av <literal>--kernel</literal>-valget, passe på å definere kjernen DomU må bruke.

en: <literal>--dhcp</literal> states that the domU's network configuration should be obtained by DHCP while <literal>--ip</literal> allows defining a static IP address.
nb-NO: <literal>--dhcp</literal> sier at DomUs nettverksoppsett skal hentes med DHCP, mens <literal>--ip</literal> lar en definere en statisk IP-adresse.

en: Lastly, a storage method must be chosen for the images to be created (those that will be seen as hard disk drives from the domU). The simplest method, corresponding to the <literal>--dir</literal> option, is to create one file on the dom0 for each device the domU should be provided. For systems using LVM, the alternative is to use the <literal>--lvm</literal> option, followed by the name of a volume group; <command>xen-create-image</command> will then create a new logical volume inside that group, and this logical volume will be made available to the domU as a hard disk drive.
nb-NO: Til slutt må lagringsmetode velges for bildet som skal opprettes (de som vil bli sett på som harddisker fra DomU). Den enkleste metoden, tilsvarende <literal>--dir</literal>-valget, er å opprette en fil på Dom0 for hver enhet der DomU skal være. For systemer som bruker LVM, er alternativet å bruke <literal>--lvm</literal>-valget, fulgt av navnet på en volumgruppe; <command>xen-create-image</command> vil deretter opprette et nytt logisk volum inne i den gruppen, og dette logiske volumet vil bli tilgjengelig for DomU-et som en harddisk.

en: <emphasis>NOTE</emphasis> Storage in the domU
nb-NO: <emphasis>MERK</emphasis> Lagring i domU

en: Entire hard disks can also be exported to the domU, as well as partitions, RAID arrays or pre-existing LVM logical volumes. These operations are not automated by <command>xen-create-image</command>, however, so editing the Xen image's configuration file is in order after its initial creation with <command>xen-create-image</command>.
nb-NO: Hele harddisker kan også bli eksportert til DomU, samt partisjoner, RAID-sett, eller eksisterende logiske data fra tidligere. Disse operasjonene blir imidlertid ikke automatisert av <command>xen-create-image</command>, så å redigere Xen-bildets oppsettsfil er greit etter det første oppsettet med <command>xen-create-image</command>.

en: Once these choices are made, we can create the image for our future Xen domU:
nb-NO: Så snart disse valgene er gjort, kan vi lage bildet til vår fremtidige Xen-DomU:

en: We now have a virtual machine, but it is currently not running (and therefore only using space on the dom0's hard disk). Of course, we can create more images, possibly with different parameters.
nb-NO: Nå har vi en virtuell maskin, men den kjører ikke for øyeblikket (og bruker derfor bare plass på harddisken til dom0). Selvfølgelig kan vi skape flere bilder, kanskje med ulike parametere.

en: Before turning these virtual machines on, we need to define how they'll be accessed. They can of course be considered as isolated machines, only accessed through their system console, but this rarely matches the usage pattern. Most of the time, a domU will be considered as a remote server, and accessed only through a network. However, it would be quite inconvenient to add a network card for each domU; which is why Xen allows creating virtual interfaces that each domain can see and use in a standard way. Note that these cards, even though they're virtual, will only be useful once connected to a network, even a virtual one. Xen has several network models for that:
nb-NO: Før du slår på disse virtuelle maskinene, må vi definere hvordan en skal få tilgang til dem. De kan selvfølgelig sees som isolerte maskiner, som bare nås gjennom sine systemkonsoller. Men dette stemmer sjelden med bruksmønsteret. Mesteparten av tiden blir en DomU betraktet som en ekstern tjener, og kun tilgjengelig gjennom et nettverk. Det vil være ganske upraktisk å legge til et nettverkskort for hver DomU; som er grunnen til at Xen tillater å lage virtuelle grensesnitt, som hvert domene kan se og bruke som standard. Merk at disse kortene, selv om de er virtuelle, bare vil være nyttige så snart de er koblet til et nettverk, selv et virtuelt et. Xen har flere nettverksmodeller for det:

en: The simplest model is the <emphasis>bridge</emphasis> model; all the eth0 network cards (both in the dom0 and the domU systems) behave as if they were directly plugged into an Ethernet switch.
nb-NO: Den enkleste er <emphasis>bridge</emphasis>-modellen. Alle eth0-nettverkskort (både i Dom0- og DomU-systemer) oppfører seg som om de var direkte koblet til en Ethernet-svitsj.

en: Then comes the <emphasis>routing</emphasis> model, where the dom0 behaves as a router that stands between the domU systems and the (physical) external network.
nb-NO: Så følger <emphasis>routing</emphasis>-modellen, hvor Dom0 oppfører seg som en ruter som står mellom DomU-systemer og det (fysiske) eksterne nettverket.

en: Finally, in the <emphasis>NAT</emphasis> model, the dom0 is again between the domU systems and the rest of the network, but the domU systems are not directly accessible from outside, and traffic goes through some network address translation on the dom0.
nb-NO: Til slutt, i <emphasis>NAT</emphasis>-modellen, der Dom0 igjen er mellom DomU-systemene og resten av nettverket, men DomU-systemene er ikke direkte tilgjengelig utenfra, og trafikken går gjennom noen nettverksadresseoversettelser på Dom0-et.

en: These three networking nodes involve a number of interfaces with unusual names, such as <filename>vif*</filename>, <filename>veth*</filename>, <filename>peth*</filename> and <filename>xenbr0</filename>. The Xen hypervisor arranges them in whichever layout has been defined, under the control of the user-space tools. Since the NAT and routing models are only adapted to particular cases, we will only address the bridging model.
nb-NO: Disse tre nettverksnodene innbefatter en rekke grensesnitt med uvanlige navn, for eksempel <filename>vif*</filename>, <filename>veth*</filename>, <filename>peth*</filename> og <filename>xenbr0</filename>. Xen-hypervisoren setter dem opp med det utlegget som har blitt definert og kontrollert av verktøy i brukerland. Siden NAT- og rutingmodellene bare er tilpasset det enkelte tilfelle, vil vi bare omtale bridge-modellen.

en: After rebooting to make sure the bridge is automatically created, we can now start the domU with the Xen control tools, in particular the <command>xl</command> command. This command allows different manipulations on the domains, including listing them and, starting/stopping them. You might need to increase the default memory by editing the variable memory from configuration file (in this case, <filename>/etc/xen/testxen.cfg</filename>). Here we have set it to 1024 (megabytes).
nb-NO: Etter å ha startet maskinen på nytt for å sørge for at brua blir opprettet automatisk, kan vi nå starte DomU med Xen-kontrollverktøyet, spesielt <command>xl</command>-kommandoen. Denne kommandoen tillater ulike håndteringer av domenene, inkludert å føre dem opp, og starte/stoppe dem. Du må kanskje øke standardminnet ved å redigere variabelminnet fra oppsettfilen (i dette tilfellet <filename>/etc/xen/testxen.cfg</filename>). Her har vi satt den til 1024 (megabyte).

en: <emphasis>TOOL</emphasis> Choice of toolstacks to manage Xen VM
nb-NO: <emphasis>VERKTØY</emphasis> Valg av verktøysamling for å håndtere Xen VM

en: <emphasis>CAUTION</emphasis> Only one domU per image!
nb-NO: <emphasis>VÆR VARSOM</emphasis> Bare ett DomU per bilde!

en: While it is of course possible to have several domU systems running in parallel, they will all need to use their own image, since each domU is made to believe it runs on its own hardware (apart from the small slice of the kernel that talks to the hypervisor). In particular, it isn't possible for two domU systems running simultaneously to share storage space. If the domU systems are not run at the same time, it is, however, quite possible to reuse a single swap partition, or the partition hosting the <filename>/home</filename> filesystem.
nb-NO: Mens det selvfølgelig er mulig å ha flere DomU-systemer som kjører parallelt, har alle behov for å bruke sitt eget bilde, siden hvert DomU er laget for å tro det kjører på sin egen maskinvare (bortsett fra den lille biten av kjernen som snakker til hypervisor). Spesielt er det ikke mulig for to DomU-systemer, som kjører samtidig, å dele lagringsplass. Hvis DomU-systemene ikke kjører samtidig, er det imidlertid fullt mulig å gjenbruke en enkel vekselminnepartisjon, eller partisjonen som er vert for filsystemet <filename>/home</filename>.

en: Note that the <filename>testxen</filename> domU uses real memory taken from the RAM that would otherwise be available to the dom0, not simulated memory. Care should therefore be taken, when building a server meant to host Xen instances, to provision the physical RAM accordingly.
nb-NO: Merk at <filename>testxen</filename>-DomU bruker virkelig minne tatt fra RAM som ellers ville være tilgjengelig for Dom0, og ikke simulert minne. Når du bygger en tjener som skal være vert for Xen-bruk, pass på å sette av tilstrekkelig fysisk RAM.

en: Voilà! Our virtual machine is starting up. We can access it in one of two modes. The usual way is to connect to it “remotely” through the network, as we would connect to a real machine; this will usually require setting up either a DHCP server or some DNS configuration. The other way, which may be the only way if the network configuration was incorrect, is to use the <filename>hvc0</filename> console, with the <command>xl console</command> command:
nb-NO: Se der! Vår virtuelle maskin starter opp. Vi får tilgang til den i en av to modi. Den vanlige måten er å koble seg til «eksternt» gjennom nettverket, slik som vi ville koble til en ekte maskin; Det vil som regel enten kreve oppsett av en DHCP-tjener, eller et DNS-oppsett. Den andre måten, som kan være den eneste måten hvis nettverksoppsettet var feil, er å bruke <filename>hvc0</filename>-konsollet, med <command>xl console</command>-kommandoen:

en: One can then open a session, just like one would do if sitting at the virtual machine's keyboard. Detaching from this console is achieved through the <keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo> key combination.
nb-NO: Man kan så åpne en økt, akkurat som man ville gjøre hvis du sitter med den virtuelle maskinens tastatur. Frakobling fra dette konsollet oppnås med <keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo>-tastekombinasjon.

en: <emphasis>TIP</emphasis> Getting the console straight away
nb-NO: <emphasis>TIPS</emphasis> Umiddelbar tilgang til konsollet

en: Sometimes one wishes to start a domU system and get to its console straight away; this is why the <command>xl create</command> command takes a <literal>-c</literal> switch. Starting a domU with this switch will display all the messages as the system boots.
nb-NO: Noen ganger ønsker man å starte et DomU-system, og med en gang få adgang til konsollet dens; dette er grunnen til at <command>xl create</command>-kommandoen aksepterer en <literal>-c</literal>-bryter. Å starte en DomU med denne bryteren vil vise alle meldingene når systemet starter.

en: Once the domU is up, it can be used just like any other server (since it is a GNU/Linux system after all). However, its virtual machine status allows some extra features. For instance, a domU can be temporarily paused then resumed, with the <command>xl pause</command> and <command>xl unpause</command> commands. Note that even though a paused domU does not use any processor power, its allocated memory is still in use. It may be interesting to consider the <command>xl save</command> and <command>xl restore</command> commands: saving a domU frees the resources that were previously used by this domU, including RAM. When restored (or unpaused, for that matter), a domU doesn't even notice anything beyond the passage of time. If a domU was running when the dom0 is shut down, the packaged scripts automatically save the domU, and restore it on the next boot. This will of course involve the standard inconvenience incurred when hibernating a laptop computer, for instance; in particular, if the domU is suspended for too long, network connections may expire. Note also that Xen is so far incompatible with a large part of ACPI power management, which precludes suspending the host (dom0) system.
nb-NO: Når DomU kjører, kan den brukes akkurat som en hvilken som helst annen tjenermaskin (siden den tross alt er et GNU/Linux-system). Imidlertid tillater den virtuelle maskinstatusen noen ekstra funksjoner. For eksempel kan en DomU midlertidig stoppes, og så begynne igjen, med kommandoene <command>xl pause</command>, og <command>xl unpause</command>. Merk at selv om DomU i pause ikke bruker noen prosessorkraft, er det tildelte minnet fortsatt i bruk. Det kan være interessant å vurdere kommandoene <command>xl save</command> og <command>xl restore</command>: Å lagre en DomU frigjør ressursene som tidligere ble brukte, inkludert RAM. Når den hentes inn igjen (eller pausen avsluttes, for den saks skyld), legger ikke DomU en gang merke til noe utover tiden som går. Hvis en DomU var i gang når Dom0 er stengt, lagrer skriptpakken automatisk DomU-et, og gjenoppretter den ved neste oppstart. Dette vil selvfølgelig medføre at de vanlige ubekvemmelighetene som oppstår når en bærbar datamaskin settes i dvalemodus. For eksempel, spesielt hvis DomU er suspendert for lenge, kan nettverkstilkoblinger gå ut på tid. Merk også at Xen så langt er uforenlig med en stor del av ACPI-strømstyringen, noe som utelukker suspensjon av Dom0-vertsystemet.

en: Halting or rebooting a domU can be done either from within the domU (with the <command>shutdown</command> command) or from the dom0, with <command>xl shutdown</command> or <command>xl reboot</command>.
nb-NO: Stopping og omstart av en DomU kan gjøres enten fra DomU-et (med <command>shutdown</command> command) eller fra Dom0, med <command>xl shutdown</command>, eller <command>xl reboot</command>.

en: Most of the <command>xl</command> subcommands expect one or more arguments, often a domU name. These arguments are well described in the <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page.
nb-NO: De fleste av <command>xl</command>-underkommandoer forventer ett eller flere argumenter, ofte et DomU-navn. Disse argumentene er godt beskrevet på manualsiden <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry>.

en: <emphasis>GOING FURTHER</emphasis> Advanced Xen
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Avansert Xen

en: Xen has many more features than we can describe in these few paragraphs. In particular, the system is very dynamic, and many parameters for one domain (such as the amount of allocated memory, the visible hard drives, the behavior of the task scheduler, and so on) can be adjusted even when that domain is running. A domU can even be migrated across servers without being shut down, and without losing its network connections! For all these advanced aspects, the primary source of information is the official Xen documentation. <ulink type="block" url="https://xenproject.org/help/documentation/" />
nb-NO: Xen har mange flere funksjoner enn vi kan beskrive i et par avsnitt. Spesielt er systemet meget dynamisk, og mange parametere for et domene (for eksempel mengden tildelt minne, synlige harddisker, oppførselen til oppgaveplanleggeren, og så videre) kan justeres selv når domenet er i gang. Et DomU kan også overføres på tvers av tjenermaskiner uten å bli slått av, og uten å miste sine nettverkstilkoblinger! For alle disse avanserte mulighetene er primærkilden til informasjon den offisielle Xen-dokumentasjonen. <ulink type="block" url="https://xenproject.org/help/documentation/" />

en: Even though it is used to build “virtual machines”, LXC is not, strictly speaking, a virtualization system, but a system to isolate groups of processes from each other even though they all run on the same host. It takes advantage of a set of recent evolutions in the Linux kernel, collectively known as <emphasis>control groups</emphasis>, by which different sets of processes called “groups” have different views of certain aspects of the overall system. Most notable among these aspects are the process identifiers, the network configuration, and the mount points. Such a group of isolated processes will not have any access to the other processes in the system, and its accesses to the filesystem can be restricted to a specific subset. It can also have its own network interface and routing table, and it may be configured to only see a subset of the available devices present on the system.
nb-NO: Selv om LXC brukes til å bygge «virtuelle maskiner», er det strengt tatt ikke et virtualiseringssystem, men et system for å isolere grupper av prosesser fra hverandre, selv om de alle kjører på den samme vertsmaskin. Det trekker veksler på et sett av nyutviklinger i Linux-kjernen, kjent som <emphasis>kontrollgrupper</emphasis>, der forskjellige sett med prosesser som kalles «grupper» har ulikt utsyn til forskjellige aspekter ved det totale systemet. Mest kjent blant disse aspektene er prosessidentifikatorene, nettverksoppsettene og monteringspunktene. En slik gruppe av isolerte prosesser vil ikke ha noen adgang til de andre prosesser i systemet, og gruppens adgang til filsystemet kan være begrenset til en spesifikk undergruppe. Den kan også ha sitt eget nettverksgrensesnitt og rutingstabell, og den kan være satt opp til å bare se et delsett av de tilgjengelige verktøy som finnes i systemet.

en: These features can be combined to isolate a whole process family starting from the <command>init</command> process, and the resulting set looks very much like a virtual machine. The official name for such a setup is a “container” (hence the LXC moniker: <emphasis>LinuX Containers</emphasis>), but a rather important difference with “real” virtual machines such as provided by Xen or KVM is that there is no second kernel; the container uses the very same kernel as the host system. This has both pros and cons: advantages include excellent performance due to the total lack of overhead, and the fact that the kernel has a global vision of all the processes running on the system, so the scheduling can be more efficient than it would be if two independent kernels were to schedule different task sets. Chief among the inconveniences is the impossibility to run a different kernel in a container (whether a different Linux version or a different operating system altogether).
nb-NO: Disse egenskapene kan kombineres for å isolere en hel prosessfamilie som starter fra <command>init</command>-prossessen, og det resulterende settet ser mye ut som en virtuell maskin. Det offisielle navnet på et slikt oppsett er en «beholder» (derav LXC-forkortelsen: <emphasis>LinuX Containers</emphasis>), men en ganske viktig forskjell til «ekte» virtuelle maskiner, som leveres av Xen eller KVM, er at det ikke er noen ekstra kjerne; beholderen bruker den samme kjernen som vertssystemet. Dette har både fordeler og ulemper: Fordelene inkluderer utmerket ytelse grunnet total mangel på ekstrabelastning, og det faktum at kjernen har full oversikt over alle prosesser som kjører på systemet, slik at planleggingen kan være mer effektiv enn hvis to uavhengige kjerner skulle planlegge ulike oppgavesett. Den største blant ulempene er at det er umulig å kjøre en annen kjerne i en beholder (enten en annen Linux-versjon, eller et annet operativsystem i det hele tatt).

en: <emphasis>NOTE</emphasis> LXC isolation limits
nb-NO: <emphasis>MERK</emphasis> LXC isolasjonsgrenser

en: LXC containers do not provide the level of isolation achieved by heavier emulators or virtualizers. In particular:
nb-NO: LXC beholdere gir ikke det isolasjonsnivået som oppnås med tyngre emulatorer eller virutaliseringer. Spesielt:

en: since the kernel is shared among the host system and the containers, processes constrained to containers can still access the kernel messages, which can lead to information leaks if messages are emitted by a container;
nb-NO: ettersom kjernen er delt mellom vertssystemet og beholderne, kan prosesser avgrenset til beholdere fortsatt få tilgang til kjernemeldinger, noe som kan føre til informasjonslekkasje hvis meldingene er sendt ut fra en beholder;

en: for similar reasons, if a container is compromised and a kernel vulnerability is exploited, the other containers may be affected too;
nb-NO: av lignende grunner, hvis en beholder er kompromittert og et sikkerhetsproblem i kjernen utnyttes, kan de øvrige beholdere også bli påvirket;

en: on the filesystem, the kernel checks permissions according to the numerical identifiers for users and groups; these identifiers may designate different users and groups depending on the container, which should be kept in mind if writable parts of the filesystem are shared among containers.
nb-NO: på filsystemet sjekker kjernen rettigheter ved hjelp av de numeriske identifikatorer for brukere og grupper. Disse identifikatorene kan henvise til forskjellige brukere og grupper avhengig av beholderen, noe en bør huske på om skrivbare deler av filsystemet er delt mellom beholdere.

en: Since we are dealing with isolation and not plain virtualization, setting up LXC containers is more complex than just running debian-installer on a virtual machine. We will describe a few prerequisites, then go on to the network configuration; we will then be able to actually create the system to be run in the container.
nb-NO: Siden vi har å gjøre med isolasjon, og ikke vanlig virtualisering, er å sette opp LXC-beholdere mer komplisert enn bare å kjøre debian-installer på en virtuell maskin. Vi vil beskrive noen forutsetninger, og går deretter videre til nettverksoppsettet. Da vil vi faktisk være i stand til å lage systemet som skal kjøres i beholderen.

en: Preliminary Steps
nb-NO: Innledende steg

en: The <emphasis role="pkg">lxc</emphasis> package contains the tools required to run LXC, and must therefore be installed.
nb-NO: Pakken <emphasis role="pkg">lxc</emphasis> inneholder de verktøyene som kreves for å kjøre LXC, og må derfor være installert.

en: LXC also requires the <emphasis>control groups</emphasis> configuration system, which is a virtual filesystem to be mounted on <filename>/sys/fs/cgroup</filename>. Since Debian 8 switched to systemd, which also relies on control groups, this is now done automatically at boot time without further configuration.
nb-NO: LXC krever også oppsettssystemet <emphasis>kontrollgrupper</emphasis>, som er et virtuelt filsystem til å monteres på <filename>/sys/fs/cgroup</filename>. Ettersom Debian 8 byttet til systemd, som også er avhengig av kontrollgrupper, gjøres dette nå automatisk ved oppstart uten ytterligere oppsett.

en: Network Configuration
nb-NO: Nettverksoppsett

en: The goal of installing LXC is to set up virtual machines; while we could, of course, keep them isolated from the network, and only communicate with them via the filesystem, most use cases involve giving at least minimal network access to the containers. In the typical case, each container will get a virtual network interface, connected to the real network through a bridge. This virtual interface can be plugged either directly onto the host's physical network interface (in which case the container is directly on the network), or onto another virtual interface defined on the host (and the host can then filter or route traffic). In both cases, the <emphasis role="pkg">bridge-utils</emphasis> package will be required.
nb-NO: Målet med å installere LXC er å sette opp virtuelle maskiner; mens vi selvfølgelig kan holde dem isolert fra nettverket, og bare kommunisere med dem via filsystemet, innebærer de fleste brukstilfeller i det minste å gi minimal nettverkstilgang til beholderne. I det typiske tilfellet vil hver beholder få et virtuelt nettverksgrensesnitt koblet til det virkelige nettverket via en bro. Dette virtuelle grensesnittet kan kobles enten direkte på vertens fysiske nettverksgrensesnitt (der beholderen er direkte på nettverket), eller på et annet virtuelt grensesnitt som er definert hos verten (og verten kan da filtrere eller rute trafikk). I begge tilfeller kreves pakken <emphasis role="pkg">bridge-utils</emphasis>.

en: <primary>network</primary><secondary><literal>br</literal> interface</secondary>
nb-NO: <primary>nettverk</primary><secondary><literal>br</literal>-grensesnitt</secondary>

en: <primary><literal>br</literal>, network interface</primary>
nb-NO: <primary><literal>br</literal>, nettverkgrensesnitt</primary>

en: They should be disabled and replaced with the following:
nb-NO: De bør deaktiveres og erstattes med følgende:

en: The effect of this configuration will be similar to what would be obtained if the containers were machines plugged into the same physical network as the host. The “bridge” configuration manages the transit of Ethernet frames between all the bridged interfaces, which includes the physical <literal>eth0</literal> as well as the interfaces defined for the containers.
nb-NO: Effekten av dette oppsettet vil ligne på hva som ville blitt oppnådd dersom beholderne var maskiner koblet til det samme fysiske nettverket som vert. Bro-oppsettet (“bridge”-oppsettet) håndterer transitt av Ethernet-rammer mellom alle bro-grensesnitt som inkluderer fysisk <literal>eth0</literal>, samt grensesnittet definert for beholderne.

en: <primary>network</primary><secondary><literal>tap</literal> interface</secondary>
nb-NO: <primary>nettverk</primary><secondary><literal>tap</literal>-grensesnitt</secondary>

en: In cases where this configuration cannot be used (for instance, if no public IP addresses can be assigned to the containers), a virtual <emphasis>tap</emphasis> interface will be created and connected to the bridge. The equivalent network topology then becomes that of a host with a second network card plugged into a separate switch, with the containers also plugged into that switch. The host must then act as a gateway for the containers if they are meant to communicate with the outside world.
nb-NO: I tilfeller der dette oppsettet ikke kan brukes (for eksempel, hvis ingen offentlige IP-adresser kan tildeles beholderne), blir et virtuelt <emphasis>tap</emphasis>-grensesnitt opprettet og koblet til broen. Den tilsvarende nettverkssammenhengen blir da som en vert med et andre nettverkskort koblet til en egen bryter, med også beholderne koblet til denne bryteren. Verten fungerer da som en inngangsport for beholdere hvis de er ment å kommunisere med omverdenen.

en: In addition to <emphasis role="pkg">bridge-utils</emphasis>, this “rich” configuration requires the <emphasis role="pkg">vde2</emphasis> package; the <filename>/etc/network/interfaces</filename> file then becomes:
nb-NO: I tillegg til <emphasis role="pkg">bridge-utils</emphasis>, krever dette «rike» oppsettet <emphasis role="pkg">vde2</emphasis>-pakken; <filename>/etc/network/interfaces</filename>-filen blir da:

en: The network can then be set up either statically in the containers, or dynamically with DHCP server running on the host. Such a DHCP server will need to be configured to answer queries on the <literal>br0</literal> interface.
nb-NO: Nettverket kan så bli satt opp enten statisk i beholderne, eller dynamisk med en DHCP-tjener som kjører hos verten. En slik DHCP-tjener må settes opp til å svare på spørsmål om <literal>br0</literal>-grensesnittet.

en: Setting Up the System
nb-NO: Oppsett av systemet

en: Note that the filesystem is initially created in <filename>/var/cache/lxc</filename>, then moved to its destination directory. This allows creating identical containers much more quickly, since only copying is then required.
nb-NO: Merk at filsystemet opprinnelig er opprettet i <filename>/var/cache/lxc</filename>, og deretter flyttet til den katalogen filsystemet skal til. Dette gjør det mulig å lage identiske beholdere mye raskere, ettersom det da bare kreves kopiering.

en: Note that the Debian template creation script accepts an <option>--arch</option> option to specify the architecture of the system to be installed and a <option>--release</option> option if you want to install something else than the current stable release of Debian. You can also set the <literal>MIRROR</literal> environment variable to point to a local Debian mirror.
nb-NO: Merk at Debian-skriptet, for å opprette maler, godtar et <option>--arch</option>-valg for å spesifisere arkitekturen til systemet som skal installeres, og et <option>--release</option>-valg hvis du ønsker å installere noe annet enn den nåværende stabile utgaven av Debian. Du kan også sette omgivelsesvariabelen <literal>MIRROR</literal> til å peke på et lokalt Debian speil.

en: <primary>service</primary><secondary><filename>lxc-net.service</filename></secondary>
nb-NO: <primary>tjeneste</primary><secondary><filename>lxc-net.service</filename></secondary>

en: <primary>network</primary><secondary><literal>veth</literal> interface</secondary>
nb-NO: <primary>nettverk</primary><secondary><literal>veth</literal>-grensesnitt</secondary>

en: <primary><literal>veth</literal>, network interface</primary>
nb-NO: <primary><literal>veth</literal>, nettverksgrensesnitt</primary>

en: Another useful entry in that file is the setting of the hostname:
nb-NO: En annen nyttig inngang i den filen er innstillingen for vertsnavnet:

en: The newly-created filesystem now contains a minimal Debian system and a network interface.
nb-NO: Det nyopprettede filsystemet inneholder nå et minimalt Debian-system og et nettverksgrensesnitt.

en: Starting the Container
nb-NO: Å starte beholderen

en: We are now in the container; our access to the processes is restricted to only those started from the container itself, and our access to the filesystem is similarly restricted to the dedicated subset of the full filesystem (<filename>/var/lib/lxc/testlxc/rootfs</filename>). We can exit the console with <keycombo action="simul"><keycap>Control</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo>.
nb-NO: Nå er vi i beholderen; vår tilgang til prosessene er begrenset til bare dem som er startet fra beholderen selv, og vår tilgang til filsystemet er tilsvarende begrenset til den øremerkede undergruppen i hele filsystemet (<filename>/var/lib/lxc/testlxc/rootfs</filename>). Vi kan gå ut av konsollen med <keycombo action="simul"><keycap>Control</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo>.

en: The <emphasis role="pkg">lxc</emphasis> package contains an initialization script that can automatically start one or several containers when the host boots (it relies on <command>lxc-autostart</command> which starts containers whose <literal>lxc.start.auto</literal> option is set to 1). Finer-grained control of the startup order is possible with <literal>lxc.start.order</literal> and <literal>lxc.group</literal>: by default, the initialization script first starts containers which are part of the <literal>onboot</literal> group and then the containers which are not part of any group. In both cases, the order within a group is defined by the <literal>lxc.start.order</literal> option.
nb-NO: Pakken <emphasis role="pkg">lxc</emphasis> inneholder et initialiseringsskript som automatisk kan starte en eller flere beholdere når verten starter opp (det er avhengig av <command>lxc-autostart</command> som starter beholdere der <literal>lxc.start.auto</literal>-valget er satt til 1). Mer finkornet kontroll over oppstartsrekkefølgen er mulig med <literal>lxc.start.order</literal> og <literal>lxc.group</literal>. Som standard starter klargjøringsskriptet først beholdere som er en del av <literal>onboot</literal>-gruppen, og deretter beholdere som ikke er en del av en gruppe. I begge tilfeller er rekkefølgen innenfor en gruppe definert av <literal>lxc.start.order</literal>-valget.

en: <emphasis>GOING FURTHER</emphasis> Mass virtualization
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Massevirtualisering

en: Since LXC is a very lightweight isolation system, it can be particularly adapted to massive hosting of virtual servers. The network configuration will probably be a bit more advanced than what we described above, but the “rich” configuration using <literal>tap</literal> and <literal>veth</literal> interfaces should be enough in many cases.
nb-NO: Siden LXC er et meget lett isolasjonssystem, kan det spesielt tilpasses til å være et massivt vertskap for virtuelle tjenere. Nettverksoppsettet vil trolig være litt mer avansert enn hva vi beskrev ovenfor, men det «rike» oppsettet som bruker <literal>tap</literal> og <literal>veth</literal>-grensesnitt skulle i mange tilfelle være nok.

en: It may also make sense to share part of the filesystem, such as the <filename>/usr</filename> and <filename>/lib</filename> subtrees, so as to avoid duplicating the software that may need to be common to several containers. This will usually be achieved with <literal>lxc.mount.entry</literal> entries in the containers configuration file. An interesting side-effect is that the processes will then use less physical memory, since the kernel is able to detect that the programs are shared. The marginal cost of one extra container can then be reduced to the disk space dedicated to its specific data, and a few extra processes that the kernel must schedule and manage.
nb-NO: Det kan også være fornuftig å ha en del av filsystemet felles, slik som <filename>/usr</filename> og <filename>/lib</filename>-undertrærne, slik at man unngår å duplisere programvaren som kanskje må være felles for flere containere. Dette vil vanligvis oppnås med <literal>lxc.mount.entry</literal>-innganger i beholdernes oppsettfil. En interessant bieffekt er at prosessene da vil bruke mindre fysisk minne, siden kjernen er i stand til å oppdage felles programmer. Den marginale belastningen for en ekstra beholder kan da reduseres til diskplassen øremerket til dens spesifikke data, og noen ekstra prosesser som kjernen må planlegge, og administrere.

en: We haven't described all the available options, of course; more comprehensive information can be obtained from the <citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry> and <citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual pages and the ones they reference.
nb-NO: Vi har selvfølgelig ikke beskrevet alle de tilgjengelige alternativene. Mer omfattende informasjon kan fås fra <citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry> og <citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry>-manualsider og sidene de refererer til.

en: Virtualization with KVM
nb-NO: Virtualisering med KVM

en: <primary>Kernel-based Virtual Machine</primary><see>KVM</see>
nb-NO: <primary>Kjerne-basert virtuell maskin</primary><see>KVM</see>

en: KVM, which stands for <emphasis>Kernel-based Virtual Machine</emphasis>, is first and foremost a kernel module providing most of the infrastructure that can be used by a virtualizer, but it is not a virtualizer by itself. Actual control for the virtualization is handled by a QEMU-based application. Don't worry if this section mentions <command>qemu-*</command> commands: it is still about KVM.
nb-NO: KVM, som står for <emphasis>Kernel-based Virtual Machine</emphasis>, er først og fremst en kjernemodul som gir det meste av infrastrukturen som kan brukes av en visualiserer, men er ikke selv en visualiserer. Faktisk kontroll av visualiseringen håndteres av en QEMU-basert applikasjon. Ikke være bekymret om denne seksjonen nevner <command>qemu-*</command>-kommandoer, den handler fremdeles om KVM.

en: Unlike other virtualization systems, KVM was merged into the Linux kernel right from the start. Its developers chose to take advantage of the processor instruction sets dedicated to virtualization (Intel-VT and AMD-V), which keeps KVM lightweight, elegant and not resource-hungry. The counterpart, of course, is that KVM doesn't work on any computer but only on those with appropriate processors. For x86-based computers, you can verify that you have such a processor by looking for “vmx” or “svm” in the CPU flags listed in <filename>/proc/cpuinfo</filename>.
nb-NO: I motsetning til andre visualiseringssystemer, ble KVM fusjonert inn i Linux-kjernen helt fra starten. Utviklerne valgte å dra nytte av prosessorens instruksjonssett øremerket til visualisering (Intel-VT og AMD-V), som holder KVM lett, elegant og ikke ressurskrevende. Motstykket, selvfølgelig, er at KVM ikke fungerer på alle datamaskiner, men bare på dem med riktige prosessorer. For x86-datamaskiner kan du bekrefte at du har en slik prosessor ved å se etter «vmx» eller «svm» i CPU-flagg oppført i <filename>/proc/cpuinfo</filename>.

en: With Red Hat actively supporting its development, KVM has more or less become the reference for Linux virtualization.
nb-NO: Med Red Hats aktive støtte til utviklingen, har KVM mer eller mindre blitt referansen for Linux-virtualisering.

en: <primary>service</primary><secondary><filename>libvirtd.service</filename></secondary>
nb-NO: <primary>tjeneste</primary><secondary><filename>libvirtd.service</filename></secondary>

en: We first install the required packages, with <command>apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer</command>. <emphasis role="pkg">libvirt-daemon-system</emphasis> provides the <command>libvirtd</command> daemon, which allows (potentially remote) management of the virtual machines running of the host, and starts the required VMs when the host boots. <emphasis role="pkg">libvirt-clients</emphasis> provides the <command>virsh</command> command-line tool, which allows controlling the <command>libvirtd</command>-managed machines.
nb-NO: Vi installerer først de nødvendige pakker med <command>apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer</command>. <emphasis role="pkg">libvirt-daemon-system</emphasis> gir bakgrunnsprosessen <command>libvirtd</command>, som tillater (potensielt ekstern) håndtering av virtuelle maskiner som kjører på verten, og starter de nødvendige VM-er når vertsmaskinen starter opp. <emphasis role="pkg">libvirt-clients</emphasis> gir <command>virsh</command>-kommandolinjeverktøyet som gjør det mulig å styre <command>libvirtd</command>-håndterte maskiner.

en: The <emphasis role="pkg">virtinst</emphasis> package provides <command>virt-install</command>, which allows creating virtual machines from the command line. Finally, <emphasis role="pkg">virt-viewer</emphasis> allows accessing a VM's graphical console.
nb-NO: Pakken <emphasis role="pkg">virtinst</emphasis> leverer <command>virt-install</command>, som tillater å lage virtuelle maskiner fra kommandolinjen. Avslutningsvis gir <emphasis role="pkg">virt-viewer</emphasis> tilgang til en VM-grafiske konsoll.

en: Just as in Xen and LXC, the most frequent network configuration involves a bridge grouping the network interfaces of the virtual machines (see <xref linkend="sect.lxc.network" />).
nb-NO: Akkurat som i Xen og LXC, innebærer det hyppigste nettverksoppsettet en bro som grupperer nettverksgrensesnittene og de virtuelle maskinene (se <xref linkend="sect.lxc.network" />).

en: Alternatively, and in the default configuration provided by KVM, the virtual machine is assigned a private address (in the 192.168.122.0/24 range), and NAT is set up so that the VM can access the outside network.
nb-NO: Alternativt, og i standardoppsettet, levert av KVM, er den virtuelle maskinen tildelt en privat adresse (i 192.168.122.0/24-området), og NAT er satt opp slik at VM kan få tilgang til nettverket utenfor.

en: The rest of this section assumes that the host has an <literal>eth0</literal> physical interface and a <literal>br0</literal> bridge, and that the former is connected to the latter.
nb-NO: Resten av denne seksjonen forutsetter at verten har et <literal>eth0</literal> fysisk grensesnitt, og en <literal>br0</literal>-bro, og den første er knyttet til den siste.

en: Installation with <command>virt-install</command>
nb-NO: Installasjon med <command>virt-install</command>

en: Creating a virtual machine is very similar to installing a normal system, except that the virtual machine's characteristics are described in a seemingly endless command line.
nb-NO: Å lage en virtuell maskin er svært lik å installere et normalt system, bortsett fra at den virtuelle maskinens egenskaper er beskrevet i en tilsynelatende uendelig kommandolinje.

en: Practically speaking, this means we will use the Debian installer, by booting the virtual machine on a virtual DVD-ROM drive that maps to a Debian DVD image stored on the host system. The VM will export its graphical console over the VNC protocol (see <xref linkend="sect.remote-desktops" /> for details), which will allow us to control the installation process.
nb-NO: I praksis betyr dette at vi vil bruke Debians installasjonsprogram ved å starte den virtuelle maskinen på en virtuell DVD-ROM-stasjon som er tilordnet til et Debian DVD-bilde som ligger hos vertssystemet. VM vil eksportere sin grafiske konsoll over VNC-protokollen (se <xref linkend="sect.remote-desktops" /> for detaljer), som tillater oss å kontrollere installasjonsprosessen.

en: <emphasis>TIP</emphasis> Add your user to the libvirt group
nb-NO: <emphasis>TIPS</emphasis> Å legge til din bruker til libvirt-gruppen

en: <primary>group</primary><secondary><literal>libvirt</literal></secondary>
nb-NO: <primary>gruppe</primary><secondary><literal>libvirt</literal></secondary>

en: All samples in this section assume that you are running commands as root. Effectively, if you want to control a local libvirt daemon, you need either to be root or to be a member of the <literal>libvirt</literal> group (which is not the case by default). Thus if you want to avoid using root rights too often, you can add yourself to the <literal>libvirt</literal> group and run the various commands under your user identity.
nb-NO: Alle eksempler i denne seksjonen forutsetter at du kjører kommandoene som rot. Effektivt, hvis du ønsker å styre en lokal libvirt-bakgrunnsprosess, må du enten være rot, eller være medlem av <literal>libvirt</literal>-gruppen (som ikke er tilfelle som standard). Så hvis du ønsker å unngå å bruke rotrettigheter for ofte, kan du legge deg selv til <literal>libvirt</literal>-gruppen, og kjøre de forskjellige kommandoene under din brukeridentitet.

en: Let us now start the installation process for the virtual machine, and have a closer look at <command>virt-install</command>'s most important options. This command registers the virtual machine and its parameters in libvirtd, then starts it so that its installation can proceed.
nb-NO: La oss nå starte installasjonsprosessen for den virtuelle maskinen, og ta en nærmere titt på de viktigste valgene til <command>virt-install</command>. Denne kommandoen registrerer den virtuelle maskinen med parametre i libvirtd, og starter den deretter slik at installasjonen kan fortsette.

en: The <literal>--connect</literal> option specifies the “hypervisor” to use. Its form is that of an URL containing a virtualization system (<literal>xen://</literal>, <literal>qemu://</literal>, <literal>lxc://</literal>, <literal>openvz://</literal>, <literal>vbox://</literal>, and so on) and the machine that should host the VM (this can be left empty in the case of the local host). In addition to that, and in the QEMU/KVM case, each user can manage virtual machines working with restricted permissions, and the URL path allows differentiating “system” machines (<literal>/system</literal>) from others (<literal>/session</literal>).
nb-NO: Valget <literal>--connect</literal> spesifiserer «hypervisoren» som skal brukes. Den har samme format som en URL som inneholder et virtualiseringssystem (<literal>xen://</literal>, <literal>qemu://</literal>, <literal>lxc://</literal>, <literal>openvz://</literal>, <literal>vbox://</literal>, og så videre), og den maskinen som skal være vert for VM (dette kan være tomt når det gjelder den lokale verten). I tillegg til det, og i QEMU/KVM tilfellet, kan hver bruker administrere virtuelle maskiner som arbeider med begrensede tillatelser, og URL-banen tillater å skille «system»-maskiner (<literal>/system</literal>) fra andre (<literal>/session</literal>).

en: Since KVM is managed the same way as QEMU, the <literal>--virt-type kvm</literal> allows specifying the use of KVM even though the URL looks like QEMU.
nb-NO: Siden KVM forvaltes på samme måte som QEMU, tillater <literal>--virt-type kvm</literal> å spesifisere bruken av KVM selv om nettadressen ser ut som QEMU.

en: The <literal>--name</literal> option defines a (unique) name for the virtual machine.
nb-NO: Valget V<literal>--name</literal> definerer et (unikt) navn for den virtuelle maskinen.

en: The <literal>--memory</literal> option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.
nb-NO: Valget <literal>--memory</literal> kan spesifisere hvor mye RAM (i MB) som skal avsettes til den virtuelle maskinen.

en: The <literal>--disk</literal> specifies the location of the image file that is to represent our virtual machine's hard disk; that file is created, unless present, with a size (in GB) specified by the <literal>size</literal> parameter. The <literal>format</literal> parameter allows choosing among several ways of storing the image file. The default format (<literal>qcow2</literal>) allows starting with a small file that only grows when the virtual machine starts actually using space.
nb-NO: <literal>--disk</literal> angir plasseringen av bildefilen som skal representere harddisken til vår virtuelle maskin; denne filen er laget, hvis den ikke allerede er til stede, med størrelsen (i GB) spesifisert av <literal>size</literal>-parameteret. <literal>format</literal>-parameteret gjør det mulig å velge mellom flere måter for lagring av bildefilen. Standardformatet (<literal>qcow2</literal>) tillater [ starte med en liten fil som bare vokser når den virtuelle maskinen faktisk begynner å bruke plass.

en: The <literal>--cdrom</literal> option is used to indicate where to find the optical disk to use for installation. The path can be either a local path for an ISO file, an URL where the file can be obtained, or the device file of a physical CD-ROM drive (i.e. <literal>/dev/cdrom</literal>).
nb-NO: <literal>--cdrom</literal>-valget brukes til å indikere hvor en finner den optiske disken til bruk ved installasjon. Banen kan enten være en lokal bane for en ISO-fil, en URL der man kan få tak i filen, eller fra disk-filen i en fysisk CD-ROM-stasjon (dvs. <literal>/dev/cdrom</literal>).

en: <primary>network</primary><secondary><literal>virbr</literal> interface</secondary>
nb-NO: <primary>nettverk</primary><secondary><literal>virbr</literal>-grensesnitt</secondary>

en: <primary><literal>virbr</literal>, network interface</primary>
nb-NO: <primary><literal>virbr</literal>, nettverksgrensesnitt</primary>

en: The <literal>--network</literal> specifies how the virtual network card integrates in the host's network configuration. The default behavior (which we explicitly forced in our example) is to integrate it into any pre-existing network bridge. If no such bridge exists, the virtual machine will only reach the physical network through NAT, so it gets an address in a private subnet range (192.168.122.0/24).
nb-NO: <literal>--network</literal> angir hvordan det virtuelle nettverkskortet integreres i vertens nettverksoppsett. Standard oppførsel (som vi eksplisitt håndhevet/tvang i vårt eksempel) er å integrere det inn i hvilken som helst foreliggende nettverksbro. Hvis en slik bro ikke finnes, vil den virtuelle maskinen kun nå det fysiske nettverket gjennom NAT, så det får en adresse i et privat delnettsområde (192.168.122.0/24).

en: The default network configuration, which contains the definition for a <literal>virbr0</literal> bridge interface, can be edited using <command>virsh net-edit default</command> and started via <command>virsh net-start default</command> if not already done automatically during system start.
nb-NO: Forvalgt nettverksoppsett som inneholder definisjonen for et <literal>virbr0</literal>-brogrensesnitt, og kan redigeres ved bruk av <command>virsh net-edit default</command> og startes via <command>virsh net-start default</command> hvis det ikke allerede gjøres automatisk under oppstart av systemet.

en: <literal>--graphics vnc</literal> states that the graphical console should be made available using VNC. The default behavior for the associated VNC server is to only listen on the local interface; if the VNC client is to be run on a different host, establishing the connection will require setting up an SSH tunnel (see <xref linkend="sect.ssh-port-forwarding" />). Alternatively, <literal>--graphics vnc,listen=0.0.0.0</literal> can be used so that the VNC server is accessible from all interfaces; note that if you do that, you really should design your firewall accordingly.
nb-NO: <literal>--graphics vnc</literal> sier at den grafiske konsollen skal gjøres tilgjengelig ved hjelp av VNC. Standard virkemåte for den tilknyttede VNC-tjeneren er å bare lytte til det lokale grensesnitt; hvis VNC-klienten skal kjøres på en annen vert, krever opprettelse av forbindelsen at det settes opp en SSH-tunnel (se <xref linkend="sect.ssh-port-forwarding" />). Alternativt kan <literal>--graphics vnc,listen=0.0.0.0</literal> anvendes slik at VNC-tjeneren er tilgjengelig fra alle grensesnitt. Vær oppmerksom på at hvis du gjør det, må du virkelig sette opp din brannmur tilsvarende .

en: The <literal>--os-type</literal> and <literal>--os-variant</literal> options allow optimizing a few parameters of the virtual machine, based on some of the known features of the operating system mentioned there.
nb-NO: <literal>--os-type</literal> og <literal>--os-variant</literal>-valgene kan optimalisere noen parametere for den virtuelle maskinen, basert på noen av de kjente funksjonene i operativsystemet nevnt der.

en: The full list of OS types can be shown using the <command>osinfo-query os</command> command from the <emphasis role="pkg">libosinfo-bin</emphasis> package.
nb-NO: Full liste over OS-typer kan vises ved bruk av <command>osinfo-query os</command>-kommandoen fra <emphasis role="pkg">libosinfo-bin</emphasis>-pakken.

en: At this point, the virtual machine is running, and we need to connect to the graphical console to proceed with the installation process. If the previous operation was run from a graphical desktop environment, this connection should be automatically started. If not, or if we operate remotely, <command>virt-viewer</command> can be run from any graphical environment to open the graphical console (note that the root password of the remote host is asked twice because the operation requires 2 SSH connections):
nb-NO: Nå kjører den virtuelle maskinen, og vi må koble til den grafiske konsollen for å fortsette med installasjonen. Hvis den forrige operasjonen ble kjørt fra et grafisk skrivebordsmiljø, bør denne forbindelsen startes automatisk. Hvis ikke, eller hvis vi operere eksternt, kan <command>virt-viewer</command> kjøres fra et hvilket som helst grafisk miljø for å åpne den grafiske konsollen (merk at det spørres om rot-passordet til den eksterne verten to ganger, fordi operasjonen krever 2 SSH-forbindelser):

en: When the installation process ends, the virtual machine is restarted, now ready for use.
nb-NO: Når installasjonsprosessen er ferdig, blir den virtuelle maskinen startet på nytt, nå klar til bruk.

en: Managing Machines with <command>virsh</command>
nb-NO: Å håndtere maskiner med <command>virsh</command>

en: Now that the installation is done, let us see how to handle the available virtual machines. The first thing to try is to ask <command>libvirtd</command> for the list of the virtual machines it manages:
nb-NO: Nå som installasjonen er ferdig, la oss se hvordan man skal håndtere de tilgjengelige virtuelle maskinene. Det første du må prøve, er å spørre <command>libvirtd</command> om listen over de virtuelle maskinene den forvalter:

en: Let's start our test virtual machine:
nb-NO: La oss starte vår test av den virtuelle maskinen:

en: We can now get the connection instructions for the graphical console (the returned VNC display can be given as parameter to <command>vncviewer</command>):
nb-NO: Vi kan nå få tilkoblingsinstruksjonene til den grafiske konsollen (den returnerte VNC-skjermen kan gis som parameter til <command>vncviewer</command>):

en: Other available <command>virsh</command> subcommands include:
nb-NO: Andre tilgjengelige underkommandoer inkluderer <command>virsh</command>:

en: <literal>reboot</literal> to restart a virtual machine;
nb-NO: <literal>reboot</literal> for å restarte en virtuell maskin;

en: <literal>shutdown</literal> to trigger a clean shutdown;
nb-NO: <literal>shutdown</literal> for å utløse en ren avslutning;

en: <literal>destroy</literal>, to stop it brutally;
nb-NO: <literal>destroy</literal>, for å stoppe den brutalt;

en: <literal>suspend</literal> to pause it;
nb-NO: <literal>suspend</literal> for å pause den;

en: <literal>resume</literal> to unpause it;
nb-NO: <literal>resume</literal> for å avslutte pause;

en: <literal>autostart</literal> to enable (or disable, with the <literal>--disable</literal> option) starting the virtual machine automatically when the host starts;
nb-NO: <literal>autostart</literal> for å aktivere (eller deaktivere, med <literal>--disable</literal>-valget) automatisk start av den virtuelle maskinen når verten starter;

en: <literal>undefine</literal> to remove all traces of the virtual machine from <command>libvirtd</command>.
nb-NO: <literal>undefine</literal> for å fjerne alle spor etter den virtuelle maskinen fra <command>libvirtd</command>.

en: All these subcommands take a virtual machine identifier as a parameter.
nb-NO: Alle disse underkommandoene tar en virtuell maskins identifikator som et parameter.

en: Automated Installation
nb-NO: Automatisert installasjon

en: <primary>deployment</primary>
nb-NO: <primary>distribusjon</primary>

en: <primary>installation</primary><secondary>automated installation</secondary>
nb-NO: <primary>installasjon</primary><secondary>automatisk installasjon</secondary>

en: The Falcot Corp administrators, like many administrators of large IT services, need tools to install (or reinstall) quickly, and automatically if possible, their new machines.
nb-NO: Falcot Corp-administratorene trenger, som mange administratorer av store IT-tjenester, verktøy for å installere sine nye maskiner (eller installere på nytt) raskt, og automatisk hvis mulig.

en: These requirements can be met by a wide range of solutions. On the one hand, generic tools such as SystemImager handle this by creating an image based on a template machine, then deploy that image to the target systems; at the other end of the spectrum, the standard Debian installer can be preseeded with a configuration file giving the answers to the questions asked during the installation process. As a sort of middle ground, a hybrid tool such as FAI (<emphasis>Fully Automatic Installer</emphasis>) installs machines using the packaging system, but it also uses its own infrastructure for tasks that are more specific to massive deployments (such as starting, partitioning, configuration and so on).
nb-NO: Disse kravene kan bli møtt av et bredt spekter av løsninger. På den ene siden, generiske verktøy som SystemImager, håndterer dette ved å skape et bilde med en maskin som mal, deretter distribuere bildet dit det skal hos systemene. I den andre enden av spekteret, kan standard Debian-installeren bli forhåndsutfylt med en oppsettsfil som gir svarene på spørsmålene under installasjonsprosessen. Som en slags middelvei, installerer et hybridverktøy som FAI (<emphasis>Fully Automatic Installer</emphasis>) maskiner ved hjelp av pakkesystemet, men det bruker også sin egen infrastruktur for oppgaver som er mer spesifikke for massive distribusjoner (som å starte, partisjonering, oppsett og så videre).

en: <foreignphrase>Fully Automatic Installer</foreignphrase> is probably the oldest automated deployment system for Debian, which explains its status as a reference; but its very flexible nature only just compensates for the complexity it involves.
nb-NO: <foreignphrase>Fully Automatic Installer</foreignphrase> er trolig det eldste automatiserte utrullingssystemet for Debian, noe som forklarer dets status som en referanse, men den svært fleksible naturen kompenserer bare akkurat for den kompleksiteten det innebærer.

en: FAI requires a server system to store deployment information and allow target machines to boot from the network. This server requires the <emphasis role="pkg">fai-server</emphasis> package (or <emphasis role="pkg">fai-quickstart</emphasis>, which also brings the required elements for a standard configuration).
nb-NO: FAI krever et tjenersystem for å lagre utrullingsinformasjon, og tillate maskinene det gjelder å starte opp fra nettverket. Denne tjeneren krever <emphasis role="pkg">fai-server</emphasis>-pakken (eller <emphasis role="pkg">fai-quickstart</emphasis>, som også bringer med seg de nødvendige elementer for et standard oppsett).

en: Creating all these configuration files requires some understanding of the way FAI works. A typical installation process is made of the following steps:
nb-NO: Å opprette alle disse oppsettsfilene krever en viss forståelse for hvordan FAI fungerer. En typisk installasjonen gjøres i følgende trinn:

en: fetching a kernel from the network, and booting it;
nb-NO: å hente en kjerne fra nettverket, og starte den;

en: mounting the root filesystem from NFS;
nb-NO: å montere rotfilssystemet fra NFS;

en: executing <command>/usr/sbin/fai</command>, which controls the rest of the process (the next steps are therefore initiated by this script);
nb-NO: å kjøre <command>/usr/sbin/fai</command>, som kontrollerer resten av prosessen (de neste trinnene er derfor initiert av dette skriptet);

en: copying the configuration space from the server into <filename>/fai/</filename>;
nb-NO: å kopiere oppsettsplassen fra tjeneren til <filename>/fai/</filename>;

en: running <command>fai-class</command>. The <filename>/fai/class/[0-9][0-9]*</filename> scripts are executed in turn, and return names of “classes” that apply to the machine being installed; this information will serve as a base for the following steps. This allows for some flexibility in defining the services to be installed and configured.
nb-NO: å kjøre <command>fai-class</command>. Skriptene <filename>/fai/class/[0-9][0-9]*</filename> blir så utført, og returnerer navnene på «klasser» som gjelder for maskinen som blir installert. Denne informasjonen vil tjene som et utgangspunkt for de neste trinnene. Dette åpner for en viss fleksibilitet i å definere hvilke tjenester som skal installeres og settes opp.

en: fetching a number of configuration variables, depending on the relevant classes;
nb-NO: å hente et antall oppsettsvariabler, avhengig av de aktuelle klasser;

en: partitioning the disks and formatting the partitions, based on information provided in <filename>/fai/disk_config/<replaceable>class</replaceable></filename>;
nb-NO: å partisjonere diskene, og formatere partisjonene, ut fra informasjon i <filename>/fai/disk_config/<replaceable>klasse</replaceable></filename>;

en: mounting said partitions;
nb-NO: montere disse partisjonene;

en: installing the base system;
nb-NO: å installere basesystemet;

en: preseeding the Debconf database with <command>fai-debconf</command>;
nb-NO: å forhåndsutfylle Debconf-databasen med <command>fai-debconf</command>;

en: fetching the list of available packages for APT;
nb-NO: å hente listen over tilgjengelige pakker for APT;

en: installing the packages listed in <filename>/fai/package_config/<replaceable>class</replaceable></filename>;
nb-NO: å installere pakkene listet i <filename>/fai/package_config/<replaceable>klasse</replaceable></filename>;

en: executing the post-configuration scripts, <filename>/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename>;
nb-NO: å kjøre etteroppsettskriptene, <filename>/fai/scripts/<replaceable>klasse</replaceable>/[0-9][0-9]*</filename>;

en: recording the installation logs, unmounting the partitions, and rebooting.
nb-NO: å registrere installasjonsloggene, avmontere partisjonene, og omstart.

en: Preseeding Debian-Installer
nb-NO: Forhåndsutfylt Debian-installer

en: <primary>preseed</primary>
nb-NO: <primary>forhåndsutfylling</primary>

en: <primary>preconfiguration</primary>
nb-NO: <primary>forhåndoppsett</primary>

en: <primary>installation</primary><secondary>preseeding</secondary>
nb-NO: <primary>installasjon</primary><secondary>forhåndsutfylling</secondary>

en: <emphasis>GOING FURTHER</emphasis> Debconf with a centralized database
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Debconf med en sentralisert database

en: Preseeding allows to provide a set of answers to Debconf questions at installation time, but these answers are static and do not evolve as time passes. Since already-installed machines may need upgrading, and new answers may become required, the <filename>/etc/debconf.conf</filename> configuration file can be set up so that Debconf uses external data sources (such as an LDAP directory server, or a remote file accessed via NFS or Samba). Several external data sources can be defined at the same time, and they complement one another. The local database is still used (for read-write access), but the remote databases are usually restricted to reading. The <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page describes all the possibilities in detail (you need the <emphasis role="pkg">debconf-doc</emphasis> package).
nb-NO: Forhåndsutfylling, preseed.cfg, gjør det mulig å gi et sett av svar på Debconf-spørsmål på installasjonstidspunktet, men disse svarene er statiske, og utvikles ikke som tiden går. Siden allerede installerte maskiner kan trenge oppgradering, og nye svar kan bli nødvendige, kan <filename>/etc/debconf.conf</filename>-oppsettsfilen settes opp slik at Debconf bruker eksterne datakilder (som en LDAP-katalogtjener, eller en ekstern fil som nås via NFS eller Samba). Flere eksterne datakilder kan defineres på samme tid, og de utfyller hverandre. Den lokale databasen brukes fortsatt (for lese- og skrivetilgang), men de eksterne databasene vanligvis er begrenset til lesing. Manualsiden <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> beskriver i detalj alle mulighetene (du trenger <emphasis role="pkg">debconf-doc</emphasis>-pakken).

en: Using a Preseed File
nb-NO: Å bruke en forhåndsutfyllingsfil

en: There are several places where the installer can get a preseeding file:
nb-NO: Det er flere steder hvor installasjonsprogrammet kan få en forhåndsutfyllingsfil:

en: in the initrd used to start the machine; in this case, preseeding happens at the very beginning of the installation, and all questions can be avoided. The file just needs to be called <filename>preseed.cfg</filename> and stored in the initrd root.
nb-NO: I initrd som brukes til å starte maskinen; i dette tilfellet skjer forhåndsutfyllingen helt i begynnelsen av installeringen, og alle spørsmålene kan unngås. Filen trenger bare å bli kalt <filename>preseed.cfg</filename>, og bli lagret i initrd-roten.

en: on the boot media (CD or USB key); preseeding then happens as soon as the media is mounted, which means right after the questions about language and keyboard layout. The <literal>preseed/file</literal> boot parameter can be used to indicate the location of the preseeding file (for instance, <filename>/cdrom/preseed.cfg</filename> when the installation is done off a CD-ROM, or <filename>/hd-media/preseed.cfg</filename> in the USB-key case).
nb-NO: På oppstartmedia (CD eller USB-nøkkel); forhåndutfylling skjer så snart media er montert, noe som betyr rett etter spørsmålene om språk og tastaturoppsett. Oppstartsparameteren <literal>preseed/file</literal> kan brukes til å indikere plasseringen av filen for forhåndsutfylling (f.eks. <filename>/cdrom/preseed.cfg</filename> når installasjonen har blitt utført fra en CD-ROM, eller <filename>/hd-media/preseed.cfg</filename> hvis fra en USB-minnepinne.

en: from the network; preseeding then only happens after the network is (automatically) configured; the relevant boot parameter is then <literal>preseed/url=http://<replaceable>server</replaceable>/preseed.cfg</literal> (HTTPS, FTPS, SFTP, etc. are not supported).
nb-NO: Fra nettverket; forhåndsutfylling skjer da bare etter at nettverket er (automatisk) satt opp; relevant oppstartsparameter er <literal>preseed/url=http://<replaceable>server</replaceable>/preseed.cfg</literal> (HTTPS, FTPS, SFTP, etc, er ikke støttet).

en: At a glance, including the preseeding file in the initrd looks like the most interesting solution; however, it is rarely used in practice, because generating an installer initrd is rather complex. The other two solutions are much more common, especially since boot parameters provide another way to preseed the answers to the first questions of the installation process. The usual way to save the bother of typing these boot parameters by hand at each installation is to save them into the configuration for <command>isolinux</command> (in the CD-ROM case) or <command>syslinux</command> (USB key).
nb-NO: Med et raskt øyekast, inkludert filen for forhåndsutfylling i initrd, ser den ut som den mest interessante løsningen; men den er imidlertid sjelden brukt i praksis, fordi å generere et installasjons-initrd er ganske komplisert. De to andre løsninger er mye mer vanlige, spesielt siden oppstartsparametere gir en annen måte til å forhåndsutfylle de første spørsmålene på i installasjonsprosessen. Den vanlige måten å spare bryet med å skrive disse oppstartsparametere for hånd på hver installasjon, er å lagre dem inn i oppsettet for <command>isolinux</command> (i CD-ROM tilfellet eller <command>syslinux</command> (ved USB-pinne).

en: Creating a Preseed File
nb-NO: Å lage en forhåndsutfyllingsfil

en: A preseed file is a plain text file, where each line contains the answer to one Debconf question. A line is split across four fields separated by whitespace (spaces or tabs), as in, for instance, <literal>d-i mirror/suite string stable</literal>:
nb-NO: En forhåndsutfyllingsfil, preseed.cfg, er en ren tekstfil, der hver linje inneholder svaret på et Debconf-spørsmål. En linje er delt i fire felt, atskilt med blanke tegn (mellomrom eller tabulatorer), som i, for eksempel,<literal>d-i mirror/suite string stable</literal>:

en: the first field is the “owner” of the question; “d-i” is used for questions relevant to the installer, but it can also be a package name for questions coming from Debian packages;
nb-NO: det første feltet er «eieren» av spørsmålet; «d-i» brukes for spørsmål som er relevante for installasjonsprogrammet, men det kan også være et pakkenavn for spørsmål som kommer fra Debian-pakker;

en: third, the type of question;
nb-NO: tredje type spørsmål;

en: the fourth and last field contains the value for the answer. Note that it must be separated from the third field with a single space; if there are more than one, the following space characters are considered part of the value.
nb-NO: det fjerde og siste feltet inneholder verdien for svaret. Legg merke til at det må være atskilt fra det tredje felt med et mellomrom; hvis det er mer enn ett, regnes følgende mellomrom som en del av verdien.

en: The simplest way to write a preseed file is to install a system by hand. Then <command>debconf-get-selections --installer</command> will provide the answers concerning the installer. Answers about other packages can be obtained with <command>debconf-get-selections</command>. However, a cleaner solution is to write the preseed file by hand, starting from an example and the reference documentation: with such an approach, only questions where the default answer needs to be overridden can be preseeded; using the <literal>priority=critical</literal> boot parameter will instruct Debconf to only ask critical questions, and use the default answer for others.
nb-NO: Den enkleste måten å skrive en forhåndsutfyllingsfil på, er å installere et system for hånd. Deretter vil <command>debconf-get-selections --installer</command> gi svar om installasjonsprogrammet. Svar om andre pakker kan oppnås med <command>debconf-get-selections</command>. Men det er en renere løsning å skrive forhåndsutfyllingsfilen for hånd, med start fra et eksempel og referansedokumentasjonen. Med en slik tilnærming trenger bare spørsmål der standardsvaret trenger å bli overstyrt, å bli forhåndsutfylt; å bruke <literal>priority=critical</literal>-oppstartsparameter vil instruere Debconf om å bare stille kritiske spørsmål, og bruke standardsvarene for andre.

en: <emphasis>DOCUMENTATION</emphasis> Installation guide appendix
nb-NO: <emphasis>DOKUMENTASJON</emphasis> Tillegg til installasjonsveiledningen

en: <primary>preseed</primary><secondary>all templates</secondary>
nb-NO: <primary>forhåndsutfylling</primary><secondary>alle maler</secondary>

en: The installation guide, available online, includes detailed documentation on the use of a preseed file in an appendix. It also includes a detailed and commented sample file, which can serve as a base for local customizations. There are also collections of all debconf templates extracted from each component and suite of Debian: <ulink type="block" url="https://www.debian.org/releases/stable/amd64/apb" /> <ulink type="block" url="https://www.debian.org/releases/stable/example-preseed.txt" /> <ulink type="block" url="https://preseed.debian.net/" />
nb-NO: Installasjonsveiledningen, som er tilgjengelig på nettet, inneholder i et tillegg en detaljert beskrivelse av bruken av en fil med forhåndsutfylte svar. Det har også med en detaljert og kommentert eksempelfil som kan tjene som basis for lokale tilpasninger. Det finnes også en samling med alle debconf-maler hentet ut fra enhver komponent og variant i Debian: <ulink type="block" url="https://www.debian.org/releases/stable/amd64/apb" /> <ulink type="block" url="https://www.debian.org/releases/stable/example-preseed.txt" /> <ulink type="block" url="https://preseed.debian.net/" />url="https://preseed.debian.net/" />

en: Preseeding an installation is often not as straightforward as one would wish. It sometimes requires to understand how packages process the given values in their scripts. Don't hesitate to ask on the <email>debian-cd@lists.debian.org</email> mailing list or in the <literal>#debian-cd</literal> IRC channel if you require help. Also be aware that some complex setups still cannot be achieved by preseeding.
nb-NO: Forhåndsutfylling av en installasjon er ofte ikke så lettbeint som man skulle ønske seg. Noen ganger er den eneste farbare veien å forstå hvordan pakkene behandler de gitte verdiene i skriptene sine. Ikke nøl med å spørre på e-postlisten <email>debian-cd@lists.debian.org</email> eller i IRC-kanalen <literal>#debian-cd</literal> hvis du trenger hjelp. Vær klar over at noen komplekse oppsett fremdeles ikke kan oppnås med forhåndsutfylling.

en: <primary>mailing lists</primary><secondary><email>debian-cd@lists.debian.org</email></secondary>
nb-NO: <primary>epostlister</primary><secondary><email>debian-cd@lists.debian.org</email></secondary>

en: Creating a Customized Boot Media
nb-NO: Å lage et skreddersydd oppstartsmedium

en: Knowing where to store the preseed file is all very well, but the location isn't everything: one must, one way or another, alter the installation boot media to change the boot parameters and add the preseed file.
nb-NO: Å vite hvor den forhåndsutfylte filen skal lagres er vel og bra, men plasseringen er ikke alt. På en eller annen måte må man få installasjonens oppstartsmedie til å endre oppstartsparametere, og legge til den forhåndsutfylte filen.

en: Booting From the Network
nb-NO: Å starte opp fra nettverket

en: When a computer is booted from the network, the server sending the initialization elements also defines the boot parameters. Thus, the change needs to be made in the PXE configuration for the boot server; more specifically, in its <filename>/tftpboot/pxelinux.cfg/default</filename> configuration file. Setting up network boot is a prerequisite; see the Installation Guide for details. <ulink type="block" url="https://www.debian.org/releases/stable/amd64/ch04s05" />
nb-NO: Når en datamaskin startes fra nettverket, vil tjeneren som sender oppstartselementene også definere oppstartsparametere. Dermed må endringene som skal gjøres, legges inn i oppstartstjenerens PXE-oppsett; mer spesifikt, i dens <filename>/tftpboot/pxelinux.cfg/default</filename>-oppsettsfil. Å sette opp nettverksoppstart er en forutsetning, se installasjonsveiledningen for mer informasjon. <ulink type="block" url="https://www.debian.org/releases/stable/amd64/ch04s05" />

en: Preparing a Bootable USB Key
nb-NO: Å forberede en oppstartbar USB-pinne (Bootable USB Key)

en: Once a bootable key has been prepared (see <xref linkend="sect.install-usb" />), a few extra operations are needed. Assuming the key contents are available under <filename>/media/usbdisk/</filename>, copy the preseed file to <filename>/media/usbdisk/preseed.cfg</filename>.
nb-NO: Så snart en oppstartbar minnepenn er klargjort (se <xref linkend="sect.install-usb" />) så trengs det noen ekstra operasjoner. Hvis vi antar at inneholdet er tilgjengelig under <filename>/media/usbdisk/</filename>, kopier forhåndsutfyllingsfilen til <filename>/media/usbdisk/preseed.cfg</filename>.

en: If you have been using a hybrid ISO image to create the bootable USB stick, then you have to edit <filename>/media/usbdisk/boot/grub/grub.cfg</filename> (for the EFI boot screen):
nb-NO: Hvis du har brukt et hybrid-ISO-avtrykk for å opprette USB-minnepinnen man kan starte opp fra må du redigere <filename>/media/usbdisk/boot/grub/grub.cfg</filename> (for EFI-oppstartsskjermen):

en: boot/grub/grub.cfg file and preseeding parameters
nb-NO: boot/grub/grub.cfg-filen og forhåndsutfyllingsparametere

en: menuentry --hotkey=i 'Install' {
        set background_color=black
        linux    /install.amd/vmlinuz preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 --- quiet 
        initrd   /install.amd/initrd.gz
    }
nb-NO: menuentry --hotkey=i 'Install' {
        set background_color=black
        linux    /install.amd/vmlinuz preseed/file=/cdrom/preseed.cfg locale=nb_NO.UTF-8 keymap=no language=nb country=NO vga=788 --- quiet 
        initrd   /install.amd/initrd.gz
    }

en: And you have to edit <filename>/media/usbdisk/isolinux/isolinux.cfg</filename> (for BIOS boot) or one of the files it utilizes - e.g. <filename>/media/usbdisk/isolinux/txt.cfg</filename> - to add required boot parameters:
nb-NO: Og du må redigerer <filename>/media/usbdisk/isolinux/isolinux.cfg</filename> (for BIOS-oppstart) eller én eller flere filer den bruker, f.eks. <filename>/media/usbdisk/isolinux/txt.cfg</filename> for å legge til oppstartsparameterne som kreves:

en: isolinux/txt.cfg file and preseeding parameters
nb-NO: isolinux/txt.cfg-fil og forhåndsutfyllingsparametre

en: label install
            menu label ^Install
            kernel [...]
            append preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=/install.amd/initrd.gz --- quiet
nb-NO: label install
            menu label ^Installer
            kernel [...]
            append preseed/file=/cdrom/preseed.cfg locale=nb_NO.UTF-8 keymap=no language=nb country=NO vga=788 initrd=/install.amd/initrd.gz --- quiet

en: If you have been using the <filename>hd-media</filename> installer image for a custom USB stick, edit <filename>/media/usbdisk/syslinux.cfg</filename> and add the required boot parameters as shown in the example below:
nb-NO: Hvis du har brukt installasjonsavtrykket <filename>hd-media</filename> til å lage en tilpasset USB-minnepinne rediger <filename>/media/usbdisk/syslinux.cfg</filename>, og legg til de nødvendige oppstartsparameterene (se eksempel nedenfor):

en: syslinux.cfg file and preseeding parameters
nb-NO: syslinux.cfg-fil og forhåndsutfyllingsparametere

en: default vmlinuz
    append preseed/file=/hd-media/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=initrd.gz  --
nb-NO: default vmlinuz
    append preseed/file=/hd-media/preseed.cfg locale=nb_NO.UTF-8 keymap=no language=nb country=NO vga=788 initrd=initrd.gz  --

en: Creating a CD-ROM Image
nb-NO: Å lage et CD-ROM-bilde

en: A USB key is a read-write media, so it was easy for us to add a file there and change a few parameters. In the CD-ROM case, the operation is more complex, since we need to regenerate a full ISO image. This task is handled by <emphasis role="pkg">debian-cd</emphasis>, but this tool is rather awkward to use: it needs a local mirror, and it requires an understanding of all the options provided by <filename>/usr/share/debian-cd/CONF.sh</filename>; even then, <command>make</command> must be invoked several times. <filename>/usr/share/debian-cd/README</filename> is therefore a very recommended read.
nb-NO: En USB-minnepenn er et lese-skrive-medium, så det var lett for oss å legge til en fil der, og endre noen parametere. I CD-ROM-tilfellet er operasjonen mer komplisert, siden vi trenger å fornye et fullt ISO-bilde. Denne oppgaven er håndtert av <emphasis role="pkg">debian-cd</emphasis>, men dette verktøyet er ganske vanskelig å bruke. Det er behov for et lokalt speil, og det krever en forståelse av alle valgene som tilbys av <filename>/usr/share/debian-cd/CONF.sh</filename>; selv da må <command>make</command> tas i bruk i flere omganger. <filename>/usr/share/debian-cd/README</filename> er derfor svært anbefalt å lese.

en: Simple-CDD: The All-In-One Solution
nb-NO: Simple-CDD: Alt i ett løsningen

en: Simply using a preseed file is not enough to fulfill all the requirements that may appear for large deployments. Even though it is possible to execute a few scripts at the end of the normal installation process, the selection of the set of packages to install is still not quite flexible (basically, only “tasks” can be selected); more important, this only allows installing official Debian packages, and precludes locally-generated ones.
nb-NO: Å bare bruke en forhåndsklargjort fil er ikke nok til å oppfylle alle krav som kan komme i store distribusjoner. Selv om det er mulig å utføre noen få skript ved slutten av den normale installasjonsprosessen, er valget av settet av pakkene til installasjon likevel ikke helt fleksibelt (i utgangspunktet kan bare «tasks» (oppgaver) velges); og viktigere, det er bare dette som tillater å installere offisielle Debian-pakker, og utelukker de lokalt genererte.

en: Creating Profiles
nb-NO: Å lage profiler

en: Simple-CDD defines “profiles” that match the FAI “classes” concept, and a machine can have several profiles (determined at installation time). A profile is defined by a set of <filename>profiles/<replaceable>profile</replaceable>.*</filename> files:
nb-NO: Simple-CDD definerer «profiler» som tilsvarer begrepet «klasser» i FAI, og en maskin kan ha flere profiler (bestemt ved installasjonstidpunktet). En profil er definert ved et sett av <filename>profiles/<replaceable>profil</replaceable>.*</filename> filer:

en: the <filename>.description</filename> file contains a one-line description for the profile;
nb-NO: <filename>.description</filename>filen inneholder en énlinjes beskrivelse av profilen;

en: the <filename>.packages</filename> file lists packages that will automatically be installed if the profile is selected;
nb-NO: <filename>.packages</filename>-filen lister pakker som automatisk vil bli installert hvis profilen er valgt;

en: the <filename>.downloads</filename> file lists packages that will be stored onto the installation media, but not necessarily installed;
nb-NO: <filename>.downloads</filename>-filen lister pakker som skal lagres på installasjonsmediet, men ikke nødvendigvis installeres;

en: the <filename>.preseed</filename> file contains preseeding information for Debconf questions (for the installer and/or for packages);
nb-NO: <filename>.preseed</filename>-filen inneholder forhåndsutfylt informasjon til Debconf-spørsmål (for installereren og/eller for pakker);

en: the <filename>.postinst</filename> file contains a script that will be run at the end of the installation process;
nb-NO: <filename>.postinst</filename>-filen inneholder et skript som blir kjørt ved slutten av installasjonen;

en: The <literal>default</literal> profile has a particular role, since it is always selected; it contains the bare minimum required for Simple-CDD to work. The only thing that is usually customized in this profile is the <literal>simple-cdd/profiles</literal> preseed parameter: this allows avoiding the question, introduced by Simple-CDD, about what profiles to install.
nb-NO: Profilen <literal>default</literal> har en spesiell rolle, da den alltid er valgt; den inneholder det rene minimum som kreves for at Simple-CDD skal fungere. Det eneste som vanligvis blir tilpasset i denne profilen, er det forhåndsutfylte <literal>simple-cdd/profiles</literal>-parameteret: Dette gjør at du unngår spørsmålet, introdusert av Simple-CDD, om hvilke profiler som skal installeres.

en: Note also that the commands will need to be invoked from the parent directory of the <filename>profiles</filename> directory.
nb-NO: Merk også at kommandoene må startes fra den overordnede katalogen til <filename>profiles</filename>-mappen.

en: Configuring and Using <command>build-simple-cdd</command>
nb-NO: Oppsett og bruk av <command>build-simple-cdd</command>

en: <emphasis>QUICK LOOK</emphasis> Detailed configuration file
nb-NO: <emphasis>RASK TITT</emphasis> Detaljert oppsettsfil

en: It is further important to familiarize yourself with the variables understood by <filename>/usr/share/debian-cd/CONF.sh</filename>.
nb-NO: Det er videre viktig å bekjentgjøre deg variablene som kan brukes i <filename>/usr/share/debian-cd/CONF.sh</filename>.

en: Simple-CDD requires many parameters to operate fully. They will most often be gathered in a configuration file, which <command>build-simple-cdd</command> can be pointed at with the <literal>--conf</literal> option, but they can also be specified via dedicated parameters given to <command>build-simple-cdd</command>. Here is an overview of how this command behaves, and how its parameters are used:
nb-NO: Simple-CDD krever mange parametere for å operere fullt ut. De vil som oftest bli samlet i en oppsettsfil, som <command>build-simple-cdd</command> kan få oppgitt med <literal>--conf</literal>-valget. Men de kan også spesifiseres via øremerkede parametere gitt til <command>build-simple-cdd</command>. Her er en oversikt over hvordan denne kommandoen oppfører seg, og hvordan dens parametere brukes:

en: the <literal>profiles</literal> parameter lists the profiles that will be included on the generated CD-ROM image;
nb-NO: <literal>profiles</literal>-parameteret lister profiler som vil bli inkludert i det genererte CD-ROM-bildet;

en: based on the list of required packages, Simple-CDD downloads the appropriate files from the server mentioned in <literal>server</literal>, and gathers them into a partial mirror (which will later be given to debian-cd);
nb-NO: basert på listen over nødvendige pakker, laster Simple-CDD ned de nødvendige filene fra tjeneren nevnt i <literal>server</literal>, og samler dem i et del-speil (som senere blir gitt til Debian-CD);

en: the custom packages mentioned in <literal>local_packages</literal> are also integrated into this local mirror;
nb-NO: de tilpassede pakkene som er nevnt i <literal>local_packages</literal> er også integrert i dette lokale speilet;

en: debian-cd is then executed (within a default location that can be configured with the <literal>debian_cd_dir</literal> variable), with the list of packages to integrate;
nb-NO: så kjøres Debian-CD (innenfor standardplasseringen som kan settes opp med <literal>debian_cd_dir</literal>-variabelen), med listen med pakker til integrering;

en: once debian-cd has prepared its directory, Simple-CDD applies some changes to this directory:
nb-NO: med en gang Debian-CD-en har forberedt sin katalog, bruker Simple-CDD noen endringer i denne katalogen:

en: files containing the profiles are added in a <filename>simple-cdd</filename> subdirectory (that will end up on the CD-ROM);
nb-NO: filer som inneholder profilene er lagt til i en <filename>simple-cdd</filename>-undermappe (som vil ende opp på CD-ROM-en);

en: other files listed in the <literal>all_extras</literal> parameter are also added;
nb-NO: andre filer som er listet i <literal>all_extras</literal>-parameteret blir også lagt til;

en: the boot parameters are adjusted so as to enable the preseeding. Questions concerning language and country can be avoided if the required information is stored in the <literal>language</literal> and <literal>country</literal> variables.
nb-NO: oppstartsparameterne er justert slik at det er mulig å aktivere forhåndsutfyllingen. Spørsmål om språk og land kan unngås hvis den aktuelle informasjonen er lagret i <literal>language</literal> og <literal>country</literal>-variablene.

en: debian-cd then generates the final ISO image.
nb-NO: deretter genererer debian-cd det endelige ISO-bildet.

en: Generating an ISO Image
nb-NO: Å generere et ISO-bilde

en: Monitoring is a generic term, and the various involved activities have several goals: on the one hand, following usage of the resources provided by a machine allows anticipating saturation and the subsequent required upgrades; on the other hand, alerting the administrator as soon as a service is unavailable or not working properly means that the problems that do happen can be fixed sooner.
nb-NO: Monitorering er en fellesbetegnelse, og de ulike involverte aktiviteter har flere mål: På den ene siden, som følge av ressursene maskinen gir, kan metning forutsees, med de påfølgende oppgraderinger som kreves. På den annen side varsles administrator så snart en tjeneste ikke er tilgjengelig, eller ikke fungerer, som betyr at oppståtte problemer kan fikses tidligere.

en: <emphasis>Munin</emphasis> covers the first area, by displaying graphical charts for historical values of a number of parameters (used RAM, occupied disk space, processor load, network traffic, Apache/MySQL load, and so on). <emphasis>Nagios</emphasis> covers the second area, by regularly checking that the services are working and available, and sending alerts through the appropriate channels (e-mails, text messages, and so on). Both have a modular design, which makes it easy to create new plug-ins to monitor specific parameters or services.
nb-NO: <emphasis>Munin</emphasis> dekker det første området, ved å vise grafiske diagrammer for historiske verdier for en rekke parametere (benyttet RAM, anvendt diskplass, prosessorbelastning, nettverkstrafikk, Apache/MySQL-last (bruk), og så videre). <emphasis>Nagios</emphasis> dekker det andre området, ved å regelmessig kontrollere at tjenestene fungerer og er tilgjengelig, og sende varsler gjennom de riktige kanaler (e-post, tekstmeldinger, og så videre). Begge har et modulært design, som gjør det enkelt å lage nye programtillegg for å følge med på bestemte parametere eller tjenester.

en: <emphasis>ALTERNATIVE</emphasis> Zabbix, an integrated monitoring tool
nb-NO: <emphasis>ALTERNATIV</emphasis> Zabbix, et integrert monitoreringsverktøy

en: <emphasis>ALTERNATIVE</emphasis> Icinga, a Nagios fork
nb-NO: <emphasis>ALTERNATIV</emphasis> Icinga, en forgrening fra Nagios

en: Setting Up Munin
nb-NO: Oppsett av Munin

en: The purpose of Munin is to monitor many machines; therefore, it quite naturally uses a client/server architecture. The central host — the grapher — collects data from all the monitored hosts, and generates historical graphs.
nb-NO: Hensikten med Munin er å monitorere mange maskiner. Derfor bruker den ganske naturlig en klient/tjener-arkitektur. Den sentrale verten - graftegneren - samler data fra alle de monitorerte vertene, og genererer historiske grafer.

en: Configuring Hosts To Monitor
nb-NO: Sette opp verter til monitor

en: The first step is to install the <emphasis role="pkg">munin-node</emphasis> package. The daemon installed by this package listens on port 4949 and sends back the data collected by all the active plugins. Each plugin is a simple program returning a description of the collected data as well as the latest measured value. Plugins are stored in <filename>/usr/share/munin/plugins/</filename>, but only those with a symbolic link in <filename>/etc/munin/plugins/</filename> are really used.
nb-NO: Det første trinnet er å installere <emphasis role="pkg">munin-node</emphasis>-pakken. Bakgrunnsprosessen som denne pakken har installert, lytter på port 4949, og sender tilbake data samlet inn av alle de aktive programtilleggene. Hvert programtillegg er et enkelt program som returnerer en beskrivelse av de innsamlede data, samt den siste målte verdi. Programtilleggene er lagret i <filename>/usr/share/munin/plugins/</filename>, men bare de med en symbolsk lenke i <filename>/etc/munin/plugins/</filename> er virkelig i bruk.

en: When the package is installed, a set of active plugins is determined based on the available software and the current configuration of the host. However, this auto-configuration depends on a feature that each plugin must provide, and it is usually a good idea to review and tweak the results by hand. Browsing the Plugin Gallery can be interesting even though not all plugins have comprehensive documentation. <ulink type="block" url="https://gallery.munin-monitoring.org" />
nb-NO: Når pakken er installert vil et sett aktive programtillegg fastsettes basert på programvaren som er tilgjengelig og nåværende oppsett av verten. Dog avhenger dette auto-oppsettet av at funksjonen er å finne i hvert programtillegg, og det er vanligvis en god idé å gjennomse og justere resultatene for hånd. Å utforske programtilleggsgalleriet kan være interessant selv om ikke alle programtillegg har fullstendig dokumentasjon. <ulink type="block" url="https://gallery.munin-monitoring.org" />

en: <primary>service</primary><secondary><filename>munin-node.service</filename></secondary>
nb-NO: <primary>tjeneste</primary><secondary><filename>munin-node.service</filename></secondary>

en: Once all plugins are correctly set up, the daemon configuration must be updated to describe access control for the collected data. This involves <literal>allow</literal> directives in the <filename>/etc/munin/munin-node.conf</filename> file. The default configuration is <literal>allow ^127\.0\.0\.1$</literal>, and only allows access to the local host. An administrator will usually add a similar line containing the IP address of the grapher host, then restart the daemon with <command>systemctl restart munin-node</command>.
nb-NO: Når alle programtilleggene er satt opp riktig, må bakgrunnsprosessoppsettet oppdateres til å beskrive adgangskontrollen for de innsamlede dataene. Dette inkluderer<literal>allow</literal>-direktiver i <filename>/etc/munin/munin-node.conf</filename>-filen. Standardoppsettet er <literal>allow ^127\.0\.0\.1$</literal>, og gir bare gir tilgang til den lokale verten. En administrator vil vanligvis legge til en lignende linje med IP-adressen til graftegner-verten, og deretter starte bakgrunnsprosessen på nytt med <command>systemctl restart munin-node</command>.

en: <emphasis>GOING FURTHER</emphasis> Creating local plugins
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Å lage lokale programtillegg

en: A plugin is best tested when run in the same conditions as it would be when triggered by munin-node; this can be simulated by running <command>munin-run <replaceable>plugin</replaceable></command> as root. A potential second parameter given to this command (such as <literal>config</literal>) is passed to the plugin as a parameter.
nb-NO: Et programtillegg kan best testes når det kjøres under samme forhold som det ville blitt når det utløses av munin-node. Dette kan simuleres ved å kjøre <command>munin-run <replaceable>plugin</replaceable></command> som rot. Et potensielt andre parameter som gis til denne kommandoen (slik som <literal>config</literal>) formidles til programtillegget som et parameter.

en: When a plugin is invoked with the <literal>config</literal> parameter, it must describe itself by returning a set of fields:
nb-NO: Når et programtillegg brukes med <literal>config</literal>-parameteret, må det beskrive seg selv ved å returnere et sett med felt:

en: The various available fields are described by the “Plugin reference” available as part of the “Munin guide”. <ulink type="block" url="https://munin.readthedocs.org/en/latest/reference/plugin.html" />
nb-NO: De forskjellige tilgjengelige feltene er beskrevet av «Plugin reference» (Plugin-referansen) som er tilgjengelig som en del av «Munin guide»-en. <ulink type="block" url="https://munin.readthedocs.org/en/latest/reference/plugin.html" />

en: When invoked without a parameter, the plugin simply returns the last measured values; for instance, executing <command>sudo munin-run load</command> could return <literal>load.value 0.12</literal>.
nb-NO: Når startet uten en parameter, vil programtillegget bare returnere de siste måleverdiene: For eksempel, å kjøre <command>sudo munin-run load</command> kunne returnere <literal>load.value 0.12</literal>.

en: Finally, when a plugin is invoked with the <literal>autoconf</literal> parameter, it should return “yes” (and a 0 exit status) or “no” (with a 1 exit status) according to whether the plugin should be enabled on this host.
nb-NO: Til slutt, når et programtillegg startes med parameteret <literal>autoconf</literal>, skal det returnere «yes» (og exit-status 0) eller «no» (med exit-status 1) avhengig av om programtillegget bør være aktivert på denne verten.

en: Configuring the Grapher
nb-NO: Oppsett av graftegneren

en: The “grapher” is simply the computer that aggregates the data and generates the corresponding graphs. The required software is in the <emphasis role="pkg">munin</emphasis> package. The standard configuration runs <command>munin-cron</command> (once every 5 minutes), which gathers data from all the hosts listed in <filename>/etc/munin/munin.conf</filename> (only the local host is listed by default), saves the historical data in RRD files (<emphasis>Round Robin Database</emphasis>, a file format designed to store data varying in time) stored under <filename>/var/lib/munin/</filename> and generates an HTML page with the graphs in <filename>/var/cache/munin/www/</filename>.
nb-NO: «Graftegneren» aggregerer rett og slett dataene, og genererer de tilhørende grafer. Den nødvendige programvaren er i <emphasis role="pkg">munin</emphasis>-pakken. Standardoppsettet kjører <command>munin-cron</command> (en gang hvert 5. minutt). Den samler data fra alle verter som er oppført i <filename>/etc/munin/munin.conf</filename> (kun den lokale verten er oppført som standard), lagrer historiske data i RRD-filer (<emphasis>Round Robin Database</emphasis>, et filformat utviklet for å lagre data som varierer i tid) lagret under <filename>/var/lib/munin/</filename>, og genererer en HTML-side med grafene i <filename>/var/cache/munin/www/</filename>.

en: All monitored machines must therefore be listed in the <filename>/etc/munin/munin.conf</filename> configuration file. Each machine is listed as a full section with a name matching the machine and at least an <literal>address</literal> entry giving the corresponding IP address.
nb-NO: Alle monitorerte maskiner må derfor være oppført i oppsettsfilen <filename>/etc/munin/munin.conf</filename>. Hver maskin er oppført som en full blokk med et navn som stemmer med maskinen, og minst et <literal>address</literal>-innslag som gir den tilhørende IP-adressen.

en: Sections can be more complex, and describe extra graphs that could be created by combining data coming from several machines. The samples provided in the configuration file are good starting points for customization.
nb-NO: Seksjoner kan være mer komplekse, og beskrive ekstra grafer laget ved å kombinere data fra flere maskiner. Prøvene som er gitt i oppsettsfilen er gode utgangspunkter for tilpasninger.

en: The last step is to publish the generated pages; this involves configuring a web server so that the contents of <filename>/var/cache/munin/www/</filename> are made available on a website. Access to this website will often be restricted, using either an authentication mechanism or IP-based access control. See <xref linkend="sect.http-web-server" /> for the relevant details.
nb-NO: Det siste trinnet er å publisere de genererte sidene. Dette innebærer å sette opp en nett-tjener, slik at innholdet i <filename>/var/cache/munin/www/</filename> blir tilgjengelig på et nettsted. Tilgang til denne nettsiden vil ofte være begrenset, enten ved hjelp av en autentiseringsmekanisme eller IP-basert adgangskontroll. Se <xref linkend="sect.http-web-server" /> for de relevante detaljene.

en: Setting Up Nagios
nb-NO: Oppsett av Nagios

en: Unlike Munin, Nagios does not necessarily require installing anything on the monitored hosts; most of the time, Nagios is used to check the availability of network services. For instance, Nagios can connect to a web server and check that a given web page can be obtained within a given time.
nb-NO: I motsetning til Munin, installerer ikke Nagios nødvendigvis noe på de monitorerte vertene. Mesteparten av tiden brukes Nagios til å kontrollere tilgjengeligheten for nettverkstjenester. For eksempel kan Nagios koble til en nett-tjener, og sjekke at en gitt nettside kan nås innen en gitt tid.

en: Installing
nb-NO: Installasjon

en: The first step in setting up Nagios is to install the <emphasis role="pkg">nagios4</emphasis> and <emphasis role="pkg">monitoring-plugins</emphasis> packages. Installing the packages configures the web interface and the Apache server. The <literal>authz_groupfile</literal> and <literal>auth_digest</literal> Apache modules must be enabled, for that execute:
nb-NO: Det første trinnet i å sette opp Nagios er å installere pakkene <emphasis role="pkg">nagios4</emphasis> og <emphasis role="pkg">monitoring-plugins</emphasis>. Installasjon av pakkene setter opp nettsidegrensesnittet og Apache-tjeneren. <literal>authz_groupfile</literal> og <literal>auth_digest</literal>/Apache-modulene må være aktivert, med den kjøringen:

en: Adding other users is a simple matter of inserting them in the <filename>/etc/nagios4/hdigest.users</filename> file.
nb-NO: For å legge til andre brukere, er en enkel sak å sette dem inn i filen <filename>/etc/nagios4/hdigest.users</filename>.

en: Pointing a browser at <literal>http://<replaceable>server</replaceable>/nagios4/</literal> displays the web interface; in particular, note that Nagios already monitors some parameters of the machine where it runs. However, some interactive features such as adding comments to a host do not work. These features are disabled in the default configuration for Nagios, which is very restrictive for security reasons.
nb-NO: Grensesnittet vises ved å la nettleseren gå til <literal>http://<replaceable>server</replaceable>/nagios4/</literal>. Vær spesielt oppmerksom på at Nagios allerede følger med på noen parametere på maskinen der den kjører. Men noen interaktive funksjoner, som å legge til kommentarer til en vert, virker ikke. Disse funksjonene er deaktivert under Nagios standardoppsett, som av sikkerhetsgrunner er svært restriktiv.

en: Enabling some features involves editing <filename>/etc/nagios4/nagios.cfg</filename>. We also need to set up write permissions for the directory used by Nagios, with commands such as the following:
nb-NO: Aktivering av noen egenskaper innebærer å redigere <filename>/etc/nagios4/nagios.cfg</filename>. Vi må også sette opp skrivetilgang til katalogen som Nagios bruker, med kommandoer som de følgende:

en: Configuring
nb-NO: Oppsett

en: The Nagios web interface is rather nice, but it does not allow configuration, nor can it be used to add monitored hosts and services. The whole configuration is managed via files referenced in the central configuration file, <filename>/etc/nagios4/nagios.cfg</filename>.
nb-NO: Nagios nettgrensesnitt er ganske fint, men det tillater ikke oppsettet, heller ikke kan det brukes til å legge til monitorerte verter og tjenester. Hele oppsettet styres via filer som det er referert til i den sentrale oppsettsfilen,<filename>/etc/nagios4/nagios.cfg</filename>.

en: These files should not be dived into without some understanding of the Nagios concepts. The configuration lists objects of the following types:
nb-NO: Disse filene bør en ikke dykke ned i uten en viss forståelse av Nagios-konsepter. Oppsettet lister objekter av følgende typer:

en: a <emphasis>host</emphasis> is a machine to be monitored;
nb-NO: en <emphasis>vert (host)</emphasis> er en maskin som skal monitoreres;

en: a <emphasis>hostgroup</emphasis> is a set of hosts that should be grouped together for display, or to factor some common configuration elements;
nb-NO: en <emphasis>vertsgruppe (hostgroup)</emphasis> er et sett av verter som bør grupperes sammen for visning, eller å utnytte vanlige oppsettselementer;

en: a <emphasis>service</emphasis> is a testable element related to a host or a host group. It will most often be a check for a network service, but it can also involve checking that some parameters are within an acceptable range (for instance, free disk space or processor load);
nb-NO: en <emphasis>service</emphasis> er et testbart element knyttet til en vert eller en gruppe verter. Det vil som oftest være en sjekk for en nettverkstjeneste, men det kan også innebære å sjekke om noen parametere er innenfor et akseptabelt spenn (for eksempel ledig diskplass eller prosessorbelastning);

en: a <emphasis>servicegroup</emphasis> is a set of services that should be grouped together for display;
nb-NO: en <emphasis>servicegruppe (servicegroup)</emphasis> er et sett av tjenester som skal grupperes sammen for visning;

en: a <emphasis>contact</emphasis> is a person who can receive alerts;
nb-NO: en <emphasis>kontakt (contact)</emphasis> er en person som kan motta varsler;

en: a <emphasis>contactgroup</emphasis> is a set of such contacts;
nb-NO: en <emphasis>kontaktgruppe (contactgroup)</emphasis> er et sett med slike kontakter;

en: a <emphasis>timeperiod</emphasis> is a range of time during which some services have to be checked;
nb-NO: en <emphasis>tidsperiode (timeperiod)</emphasis> er et tidsspenn innenfor hvilket enkelte tjenester må kontrolleres;

en: a <emphasis>command</emphasis> is the command line invoked to check a given service.
nb-NO: en <emphasis>kommando (command)</emphasis> er kommandolinjen som brukes for å sjekke en gitt tjeneste.

en: According to its type, each object has a number of properties that can be customized. A full list would be too long to include, but the most important properties are the relations between the objects.
nb-NO: Alt etter typen, har hvert objekt en rekke egenskaper som kan tilpasses. En fullstendig liste ville bli for lang til å ta med her, men de viktigste egenskapene er forholdet mellom objektene.

en: A <emphasis>service</emphasis> uses a <emphasis>command</emphasis> to check the state of a feature on a <emphasis>host</emphasis> (or a <emphasis>hostgroup</emphasis>) within a <emphasis>timeperiod</emphasis>. In case of a problem, Nagios sends an alert to all members of the <emphasis>contactgroup</emphasis> linked to the service. Each member is sent the alert according to the channel described in the matching <emphasis>contact</emphasis> object.
nb-NO: En <emphasis>service</emphasis> bruker en <emphasis>kommando (command)</emphasis> til å sjekke statusen til en egenskap på en <emphasis>vert (host)</emphasis> (eller en <emphasis>vertsgruppe (hostgroup)</emphasis>) innenfor en <emphasis>tidsperiode (timeperiod)</emphasis>. Om det oppstår et problem, sender Nagios et varsel til alle medlemmer av <emphasis>kontaktgruppe (contactgroup)</emphasis> knyttet til tjenesten. Hvert medlem får sendt varselet ifølge den kanalen som er beskrevet i det samsvarende <emphasis>kontakt (contact)</emphasis>-objektet.

en: An inheritance system allows easy sharing of a set of properties across many objects without duplicating information. Moreover, the initial configuration includes a number of standard objects; in many cases, defining new hosts, services and contacts is a simple matter of deriving from the provided generic objects. The files in <filename>/etc/nagios4/conf.d/</filename> are a good source of information on how they work.
nb-NO: Et arvesystem tillater enkel deling av et sett med egenskaper på tvers av mange objekter uten å duplisere informasjon. Videre har det opprinnelige oppsettet en rekke standardobjekter; i mange tilfeller er det å definere nye verter, tjenester og kontakter en enkel sak å utlede fra de angitte generiske objektene. Filene i <filename>/etc/nagios4/conf.d/</filename> er en god kilde til informasjon om hvordan de fungerer.

en: The Falcot Corp administrators use the following configuration:
nb-NO: Falcot Corp-administratorene bruker følgende oppsett:

en: <filename>/etc/nagios4/conf.d/falcot.cfg</filename> file
nb-NO: <filename>/etc/nagios4/conf.d/falcot.cfg</filename>-fil

en: This configuration file describes two monitored hosts. The first one is the web server, and the checks are made on the HTTP (80) and secure-HTTP (443) ports. Nagios also checks that an SMTP server runs on port 25. The second host is the FTP server, and the check includes making sure that a reply comes within 20 seconds. Beyond this delay, a <emphasis>warning</emphasis> is emitted; beyond 30 seconds, the alert is deemed critical. The Nagios web interface also shows that the SSH service is monitored: this comes from the hosts belonging to the <literal>ssh-servers</literal> hostgroup. The matching standard service is defined in <filename>/etc/nagios4/conf.d/services_nagios2.cfg</filename>.
nb-NO: Denne oppsettsfilen beskriver to monitorerte verter. Den første er nett-tjeneren, og kontrollene er gjort på HTTP (80) og sikre-HTTP (443) porter. Nagios sjekker også at en SMTP-tjener kjører på port 25. Den andre verten er FTP-tjeneren, og sjekken inkluderer å sørge for at svar kommer innen 20 sekunder. Utover denne forsinkelsen, blir en <emphasis>advarsel</emphasis> sendt ut; med mer enn 30 sekunder ansees varslingen som kritisk. Nagios nettgrensesnitt viser også at SSH-tjenesten sjekkes; dette kommer fra vertene som tilhører vertsgruppen <literal>ssh-servers</literal>. Den samsvarende standardtjenesten er definert i <filename>/etc/nagios4/conf.d/services_nagios2.cfg</filename>.

en: Note the use of inheritance: an object is made to inherit from another object with the “use <replaceable>parent-name</replaceable>”. The parent object must be identifiable, which requires giving it a “name <replaceable>identifier</replaceable>” property. If the parent object is not meant to be a real object, but only to serve as a parent, giving it a “register 0” property tells Nagios not to consider it, and therefore to ignore the lack of some parameters that would otherwise be required.
nb-NO: Legg merke til bruken av arv: Et objekt er satt til å arve fra et annet objekt med «bruk <replaceable>foreldre-navn</replaceable>». Foreldre-objektet må kunne identifiseres, noe som krever å gi det et «navn <replaceable>identifikator</replaceable>»-egenskap. Hvis det overordnede objektet ikke er ment å være et reelt objekt, men bare skal tjene som en forelder, og gir det en «register 0»-egenskap som sier til Nagios om å ikke vurdere det, og derfor om å ignorere mangelen på noen parametere som ellers ville vært nødvendig.

en: <emphasis>DOCUMENTATION</emphasis> List of object properties
nb-NO: <emphasis>DOKUMENTASJON</emphasis> Liste med objektegenskaper

en: <emphasis>GOING FURTHER</emphasis> Remote tests with NRPE
nb-NO: <emphasis>FOR VIDEREKOMMENDE</emphasis> Eksterne tester med NRPE

en: Many Nagios plugins allow checking some parameters local to a host; if many machines need these checks while a central installation gathers them, the NRPE (<emphasis>Nagios Remote Plugin Executor</emphasis>) plugin needs to be deployed. The <emphasis role="pkg">nagios-nrpe-plugin</emphasis> package needs to be installed on the Nagios server, and <emphasis role="pkg">nagios-nrpe-server</emphasis> on the hosts where local tests need to run. The latter gets its configuration from <filename>/etc/nagios/nrpe.cfg</filename>. This file should list the tests that can be started remotely, and the IP addresses of the machines allowed to trigger them. On the Nagios side, enabling these remote tests is a simple matter of adding matching services using the new <command>check_nrpe</command> command.
nb-NO: Mange av Nagios programtillegg tillater å sjekke noen parametere lokalt hos en vert; hvis mange maskiner trenger disse kontrollene, og en sentral installasjon samler dem, så må en legge inn programtillegget NRPE (<emphasis>Nagios Remote Plugin Executor</emphasis>). <emphasis role="pkg">nagios-nrpe-plugin</emphasis>-pakken må installeres på Nagios tjeneren, og <emphasis role="pkg">nagios-nrpe-server</emphasis> på vertene der lokale tester skal kjøres. Sistnevnte får sitt oppsett fra <filename>/etc/nagios/nrpe.cfg</filename>. Denne filen skal inneholde de testene som kan startes over nettet, og IP-adressene til maskinene som får lov til å starte dem. På Nagios-siden aktivers disse eksterne testene ved å legge aktuelle tjenester ved hjelp av den nye <command>check_nrpe</command>-kommandoen.
