0 - en to pt-BR translation catalogue (368 entries)

en: Preseeding
pt-BR: Pré-configuração

en: Monitoring
pt-BR: Monitoramento

en: Virtualization
pt-BR: Virtualização

en: Advanced Administration
pt-BR: Administração Avançada

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.
pt-BR: Este capítulo retoma alguns aspectos já descritos, com uma perspectiva diferente: em vez de instalar em um único computador, vamos estudar a implantação de sistemas em massa; em vez de criar volumes RAID ou LVM no momento da instalação, vamos aprender a fazer tudo na mão para que mais tarde possamos rever nossas escolhas iniciais. Finalmente, vamos discutir as ferramentas de monitoramento e técnicas de virtualização. Como consequência, este capítulo é mais particularmente alvo de administradores profissionais e centra-se um pouco menos nos indivíduos responsáveis pela sua rede doméstica.

en: RAID and LVM
pt-BR: RAID e LVM

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.
pt-BR: RAID e LVM são duas técnicas para abstrair os volumes montados a partir de seus equivalentes físicos (reais unidades de disco rígido ou partições do mesmo), o primeiro garante a segurança e a disponibilidade dos dados em caso de falhas no hardware através da introdução de redundância, o último torna o gerenciamento de volumes mais flexível e independente do tamanho real nos discos. Em ambos os casos, o sistema acaba com novos volumes (partições, blocos), que podem ser usados para criar sistemas de arquivos ou espaço de troca, sem necessariamente ter eles mapeados em um disco físico. LVM e RAID vêm de origens bem diferentes, mas sua funcionalidade pode sobrepor-se um pouco, é por isso que eles são muitas vezes mencionados juntos.

en: <emphasis>PERSPECTIVE</emphasis> Btrfs combines LVM and RAID
pt-BR: <emphasis>PERSPECTIVE</emphasis> Btrfs combina LVM e 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.
pt-BR: Entre as características marcantes estão a capacidade de tirar um instantâneo de uma árvore de diretórios em qualquer ponto no tempo. Este instantâneo inicialmente não utiliza nenhum espaço em disco, os dados só serão duplicados quando um dos arquivos copiados for modificado. O sistema de arquivos também lida com a compressão transparente de arquivos e somas de verificação (checksums) garantem a integridade de todos os dados armazenados.

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.
pt-BR: Em ambos os casos RAID e LVM, o kernel fornece um arquivo de dispositivo de bloco semelhantes aos que correspondem a uma unidade de disco rígido ou partição. Quando um pedido ou uma outra parte do núcleo, requer o acesso a um bloco de um tal dispositivo, as rotas de subsistemas apropriadas do bloco são usadas para a camada física relevante. Dependendo da configuração, este bloco pode ser armazenado em um ou vários discos físicos e sua localização física pode não ser diretamente relacionada com a localização do bloco no dispositivo lógico.

en: Software RAID
pt-BR: RAID Por Software

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.
pt-BR: RAID significa <emphasis> Redundant Array of Independent Disks - conjunto redundante de discos independentes</emphasis>. O objetivo deste sistema é evitar perda de dados e garantir sua disponibilidade em caso de falha do disco rígido. O princípio geral é bastante simples: os dados são armazenados em vários discos físicos em vez de apenas um, com um nível configurável de redundância. Dependendo desta quantidade de redundância, e mesmo no caso de uma falha de disco inesperado, dados podem ser reconstruídos sem perdas dos restantes discos.

en: <emphasis>CULTURE</emphasis> <foreignphrase>Independent</foreignphrase> or <foreignphrase>inexpensive</foreignphrase>?
pt-BR: <emphasis>CULTURA</emphasis> <foreignphrase>Independent</foreignphrase> or <foreignphrase>inexpensive</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.
pt-BR: O I da sigla RAID inicialmente significava <emphasis>inexpensive</emphasis> (barato), por que o RAID permitia um aumento drástico na segurança de dados sem precisar investir em discos de alta qualidade. Provavelmente, devido a questões de melhoria da imagem, o I é agora normalmente chamado de <emphasis>independent</emphasis> (independente), para não ficar com esta impressão de baixo custo.

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.
pt-BR: O RAID pode ser implementado tanto por hardware dedicado (módulos RAID integrados em placas controladoras SCSI ou SATA) ou por abstração de software (o núcleo). Seja por hardware ou software, um sistema RAID com redundância suficiente pode, de forma transparente, continuar operacional quando um disco falha; as camadas superiores da pilha (aplicações) podem até manter o acesso aos dados apesar da falha. Claro que, esse “modo degradado” pode ter impacto na performance, e a redundância é reduzida, então uma falha profunda do disco pode levar a perda de dados. Na prática, entretanto, um irá se esforçar para apenas ficar nesse modo degradado o tempo que for necessário para que se possa substituir o disco falho. Uma vez que o novo disco seja colocado, o sistema RAID pode reconstruir os dados necessários e então retornar ao modo seguro. As aplicações não notarão nada, fora a potencial redução da velocidade de acesso, enquanto a array estiver no modo degradado ou durante a fase de reconstrução.

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).
pt-BR: Quando o RAID é implementado por hardware, sua configuração geralmente acontece dentro da ferramenta de configuração da BIOS, e o núcleo irá considerar uma array RAID como um único disco, que irá funcionar como um disco físico padrão, embora o nome do dispositivo possa ser diferente (dependendo do driver).

en: We only focus on software RAID in this book.
pt-BR: Nós apenas focamos em RAID de software neste livro.

en: Different RAID Levels
pt-BR: Diferentes Níveis de RAID

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.
pt-BR: RAID não é na verdade um único sistema, mas vários sistemas identificados por seus níveis; os níveis diferem por sua disposição e quantidade de redundância que eles fornecem. Quanto mais redundante, mais à prova de falhas, uma vez que o sistema será capaz de continuar a trabalhar quando mais discos falharem. A contrapartida é que reduz o espaço utilizável para um dado conjunto de discos; visto de outra forma, mais discos serão necessários para armazenar a mesma quantidade de dados.

en: Linear RAID
pt-BR: RAID Linear

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.
pt-BR: Mesmo o que o subsistema de RAID do núcleo permita a criação de um “RAID linear”, isso não é um RAID propriamente, já que essa configuração não envolve qualquer redundância. O núcleo apenas agrega vários discos fim-a-fim e provê o volume agregado resultante como um disco virtual (um dispositivo de bloco). Essa é sua única função. Essa configuração raramente é usada por ela própria (veja mais adiante sobre as exceções), especialmente porque a falta de redundância significa que a falha de um disco faz com que todo o agregado, e portanto todos os dados, fiquem indisponíveis.

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.
pt-BR: Esse nível também não provê nenhuma redundância, mas os discos não são simplesmente ligados pelo final um após o outro: eles são divididos em <emphasis>listras (stripes)</emphasis>, e os blocos no dispositivo virtual são armazenados em listras (stripes) em discos físicos alternados. Em uma configuração de RAID-0 de dois discos, por exemplo, em blocos de número par do dispositivo virtual serão armazenados no primeiro disco físico, enquanto os blocos ímpares ficarão no segundo disco físico.

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.
pt-BR: Esse sistema não tem por objetivo um aumento de credibilidade, já que (como em um caso linear) a disponibilidade de todos os dados é comprometida assim que um disco falhar, mas um aumento de desempenho: durante um acesso sequencial a grandes quantidades de dados contíguos, o núcleo será capaz de ler a partir dos dois discos (ou escrever neles) em paralelo, o que incrementa a taxa de transferência de dados. Os discos são inteiramente utilizados pelo dispositivo RAID, para que ele possam ter o mesmo tamanho sem prejuízo da performance.

en: RAID-0 use is shrinking, its niche being filled by LVM (see later).
pt-BR: O uso de RAID-0 está diminuindo, seu nicho está sendo ocupado pelo LVM (veremos mais adiante).

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.
pt-BR: Esse nível, também conhecido como “espelhamento RAID”, é tanto o mais simples quanto a mais amplamente usada configuração. Em sua forma padrão, ele usa dois discos físicos de mesmo tamanho e fornece um volume lógico de mesmo tamanho mais uma vez. Os dados são armazenados identicamente nos dois discos, por isso o apelido “espelho”. Quando um disco falha, os dados ainda estão disponíveis no outro. Para dados realmente críticos, RAID-1 pode, é claro, ser configurado para mais de dois discos, com impacto direto na relação de custo de hardware versus espaço de carga disponível.

en: <emphasis>NOTE</emphasis> Disks and cluster sizes
pt-BR: <emphasis>NOTA</emphasis> Discos e tamanhos de cluster

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.
pt-BR: Se dois discos de tamanhos diferentes são criados em um espelho, o maior não será totalmente usado, pois ele irá conter os mesmos dados como o menor e nada mais. O espaço útil disponível fornecido por um volume RAID-1, portanto, corresponde ao tamanho do disco menor na matriz. Isso ainda vale para volumes RAID com um maior nível RAID, apesar de redundância é armazenada de forma diferente.

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.
pt-BR: Por isso é importante, ao configurar arrays RAID (exceto RAID-0 "RAID linear"), só montar discos de tamanhos idênticos, ou muito perto, para evitar o desperdício de recursos.

en: <emphasis>NOTE</emphasis> Spare disks
pt-BR: <emphasis>NOTA</emphasis> Discos de reposição

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.
pt-BR: Níveis RAID que incluem redundância permitem atribuir mais discos do que o necessário para uma array. Os discos extras são usados como reservas quando um dos principais discos falha. Por exemplo, em um espelho de dois discos e mais um reserva, se um dos dois primeiros discos falhar, o núcleo irá automaticamente (e imediatamente) reconstruir o espelho usando o disco reserva, para que a redundância continue garantida após o momento de reconstrução. Isso pode ser usado como outro tipo de salva guarda para dados críticos.

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.
pt-BR: Alguém poderia ser perdoado por questionar como isso pode ser melhor do que simplesmente espelhar três discos como início. A vantagem da configuração de um “disco reserva” é que o disco reserva pode ser compartilhado entre vários volumes RAID. Por exemplo, é possível ter três volumes espelhados, com garantia de redundância mesmo no caso de falha de um disco, com apenas sete discos (três pares, mais um reserva compartilhado), ao invés dos nove discos que seriam necessários para três trigêmeos.

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.
pt-BR: Esse nível de RAID, embora caro (já que apenas metade do espaço físico de armazenagem, na melhor das hipóteses, é útil), é amplamente usado na prática. Ele é simples de entender, e ele permite cópias de segurança (backups) bem simples: como os dois discos tem conteúdos idênticos, um deles pode ser temporariamente extraído, sem impacto no sistema em funcionamento. O desempenho de leitura geralmente é incrementado , já que o núcleo pode ler metade dos dados em cada disco, em paralelo, enquanto o desempenho de escrita não é muito severamente degradado. No caso de uma array RAID-1 de N discos, os dados continuam disponíveis mesmo com a falha do disco N-1.

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.
pt-BR: Esse nível de RAID, não amplamente usado, usa N discos para armazenar dados úteis, e um disco extra para armazenar informação redundante. Se esse disco falhar, o sistema pode reconstruir seu conteúdo a partir do outro N. Se um dos N discos de dados falhar, O N-1 remanescente combinado com o disco “paridade” contém informação suficiente para reconstruir os dados requeridos.

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).
pt-BR: RAID-4 não é muito caro já que ele apenas envolve um incremento de um-em-N nos custos e não se tem impacto perceptível no desempenho de leitura, mas a escrita é mais devagar. Além disso, como uma escrita em qualquer um dos N discos também envolve a escrita no disco de paridade, esse último tem muito mais escritas que o anterior, e sua vida útil pode ser dramaticamente diminuída como consequência. Os dados na array RAID-4 só está segura até um disco falhar (dos 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.
pt-BR: RAID-5 resolve o problema de assimetria do RAID-4: a paridade de blocos é distribuída por todos os N+1 discos, sendo que nenhum tem um papel particular.

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.
pt-BR: A performance de leitura e escrita são idênticas ao RAID-4. Aqui novamente, o sistema continua funcional mesmo com a falha de um disco (do N+1), mas não mais.

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.
pt-BR: RAID-6 pode ser considerado uma extensão do RAID-5, onde cada série de N blocos envolvem dois blocos redundantes, e cada série de N+2 blocos e distribuída sobre N+2 discos.

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.
pt-BR: Esse nível de RAID é levemente mais caro que os dois anteriores, mas ele traz alguma segurança extra já que até dois drives (dos N+2) podem falhar sem comprometer a disponibilidade dos dados. A contraparte é que as operações de escrita agora envolvem escrever um bloco de dados e dois blocos de redundância, o que os torna ainda mais lento.

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.
pt-BR: Isso não é, estritamente falando, um nível RAID, mas um empilhamento de dois agrupamentos RAID. A partir de 2×N discos, primeiro se configura eles por pares em volumes N RAID-1; esses volumes N são então agregados em um só, seja por “linear RAID” ou (cada vez mais) por LVM. Esse último caso vai além do puro RAID, mas não existe problema quanto a isso.

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.
pt-BR: RAID-1+0 pode sobreviver com múltiplas falhas nos discos: até N na 2xN série descrita acima, provendo ao menos um disco funcional em cada par de RAID-1.

en: <emphasis>GOING FURTHER</emphasis> RAID-10
pt-BR: <emphasis>Aprofundando</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.
pt-BR: RAID-10 é ,geralmente , considerado um sinônimo de RAID-1+0, mas uma especifidade Linux faz com que ele seja realmente uma generalização. Essa configuração permite um sistema aonde cada bloco seja armazenado em dois diferentes discos, mesmo com um número impar de discos, sendo as cópias espalhadas ao longo de um modelo configurável.

en: Performances will vary depending on the chosen repartition model and redundancy level, and of the workload of the logical volume.
pt-BR: A performance variará dependendo da escolha do modelo de repartição e do nível de redundância, e da carga de trabalho do volume lógico.

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.
pt-BR: Obviamente, o nível de RAID será escolhido de acordo com as restrições e requerimentos de cada aplicação. Note que um computador sozinho pode ter diversos tipos de RAIDs distintos com diversas configurações.

en: Setting up RAID
pt-BR: Configurando um RAID

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.
pt-BR: Configurar volumes RAID requer o pacote <emphasis role="pkg">mdadm</emphasis>; ele provê o comando <command>mdadm</command>, que permite a criação e manipulação de arrays RAID, assim como scripts e ferramentas para integração com o resto do sistema, incluindo o sistema de monitoração.

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:
pt-BR: Nossos exemplo será um servidor com um número de discos, sendo que alguns já estão em uso, e o resto está disponível para a configuração do RAID. Nós inicialmente temos os seguintes discos e partições:

en: the <filename>sdb</filename> disk, 4 GB, is entirely available;
pt-BR: o disco <filename>sdb</filename>, 4 GB, está completamente disponível;

en: the <filename>sdc</filename> disk, 4 GB, is also entirely available;
pt-BR: o disco <filename>sdc</filename>, 4 GB, também está completamente disponível;

en: on the <filename>sdd</filename> disk, only partition <filename>sdd2</filename> (about 4 GB) is available;
pt-BR: no disco <filename>sdd</filename>, somente a partição <filename>sdd2</filename> (cerca de 4 GB) está disponível;

en: finally, a <filename>sde</filename> disk, still 4 GB, entirely available.
pt-BR: finalmente, um disco <filename>sde</filename>, ainda com 4 GB, disponível.

en: <emphasis>NOTE</emphasis> Identifying existing RAID volumes
pt-BR: <emphasis>NOTA</emphasis> Identificando os volumes RAID existentes

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.
pt-BR: O arquivo <filename>/proc/mdstat</filename> lista os volumes existentes e seus estados. Quando criando um novo volume RAID, devemos tomar cuidado para não nomeá-lo da mesma maneira que um volume existente.

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:
pt-BR: Iremos usar estes elementos físicos para criar dois volumes, um RAID-0 e um espelho (RAID-1). Comecemos com o volume RAID-0:

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>.
pt-BR: O comando <command>mdadm --create</command> requer vários parâmetros: o nome do volume a ser criado (<filename>/dev/md*</filename>, com MD significando <foreignphrase>Multiple Device</foreignphrase>), o nível RAID, o número de discos (que é obrigatório, apesar de ser significante apenas com RAID-1 e acima), e os drives físicos a usar. Uma vez que o dispositivo seja criado, nós podemos usá-lo como usamos uma partição normal, criando um sistema de arquivos nela, montando esse sistema de arquivos, e assim por diante. Note que nossa criação de um volume RAID-0 em <filename>md0</filename> não passa de coincidência, e a numeração da array não precisa ser correlacionada com a quantidade escolhida de redundância. Também é possível criar arrays RAID nomeadas, dando ao <command>mdadm</command> parâmetros como <filename>/dev/md/linear</filename> ao invés de <filename>/dev/md0</filename>.

en: Creation of a RAID-1 follows a similar fashion, the differences only being noticeable after the creation:
pt-BR: A criação do RAID-1 segue estilo similar, as diferenças somente serão notadas após a criação:

en: <emphasis>TIP</emphasis> RAID, disks and partitions
pt-BR: <emphasis>DICA</emphasis> RAID, discos e partições

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.
pt-BR: Algumas observações em ordem. Primeiro, <command>mdadm</command> nota que os elementos físicos possuem tamanhos diferentes; já que isso implica que algum espaço será perdido no maior elemento, uma confirmação é necessária.

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.
pt-BR: Ainda mais importante, note o estado do espelhamento.O estado normal de um espelho RAID é que os dois discos tenham exatamente o mesmo conteúdo. Contudo, nada garante que esse é o caso quando o volume é criado pela primeira vez. O subsistema RAID irá, por conseguinte, prover essa garantia por si mesmo, e acontecerá uma fase de sincronização assim que o dispositivo RAID for criado. Após algum tempo (a quantidade exata irá depender do real tamanho dos discos…), a array RAID alternará para o estado “ativo” ou "limpo". Note que durante essa fase de reconstrução, o espelho está em modo degradado, e a redundância não é garantida. Um disco falhando durante essa janela de risco poderia levar a perda de todos os dados. Grandes quantidades de dados críticos, contudo, raramente são armazenados em uma array RAID recentemente criada, antes de sua sincronização inicial. Note que mesmo em modo degradado, o <filename>/dev/md1</filename> é usável, e um sistema de arquivos pode ser criado nele, assim como alguns dados podem ser copiados para ele.

en: <emphasis>TIP</emphasis> Starting a mirror in degraded mode
pt-BR: <emphasis>DICA</emphasis> Começando um espelho em modo reduzido

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.
pt-BR: Às vezes, dois discos não estão imediatamente disponíveis quando se quer iniciar um espelho RAID-1, por exemplo, porque se pretende incluir um dos discos já usado para armazenar os dados que se quer passar para a array. Em tais circunstâncias, é possível criar deliberadamente uma degradada array RAID-1, passando <filename>missing</filename> em vez de um arquivo de dispositivo como um dos argumentos para <command>mdadm</command>. Uma vez que os dados tenham sido copiados para o "espelho", o disco antigo pode ser adicionado à array. A sincronização irá então acontecer, dando-nos a redundância que foi desejada, em primeiro lugar.

en: <emphasis>TIP</emphasis> Setting up a mirror without synchronization
pt-BR: <emphasis>DICA</emphasis> Configurando um espelho sem sincronização

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.
pt-BR: Volumes RAID-1 são geralmente criados para serem usados como disco novo, geralmente considerados vazios. O conteúdo inicial real do disco portanto não é muito relevante, já que alguém apenas precisa saber que os dados escritos após a criação do volume, em particular o sistema de arquivos, podem ser acessados mais tarde.

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?
pt-BR: Pode-se portanto querer saber sobre o ponto de sincronização de ambos os discos no momento da criação. Por que se importar se os conteúdos são idênticos em zonas do volume que nós sabemos que apenas serão lidas após nós termos escrito nelas?

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.
pt-BR: Felizmente, essa fase de sincronização pode ser evitada passando a opção <literal>--assume-clean</literal> para <command>mdadm</command>. Contudo, essa opção pode levar a surpresas no caso de os dados iniciais serem lidos (por exemplo se um sistema de arquivos já esteja presente nos discos físicos), que é o por que dela não ser habilitada por padrão.

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:
pt-BR: Agora vamos ver o que acontece quando um dos elementos da array RAID-1 falha. O <command>mdadm</command>, em particular sua opção <literal>--fail</literal>, permite simular uma falha de disco desse tipo:

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>:
pt-BR: O conteúdo do volume ainda está acessível (e, se montado, as aplicações não notarão nada), mas a segurança dos dados não é mais garantida: se, por sua vez, o disco <filename>sdd</filename> falhar, os dados serão perdidos. Nós queremos evitar esse risco, então vamos substituir o disco falho por um novo, <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:
pt-BR: Aqui, mais uma vez, o núcleo automaticamente dispara uma fase de reconstrução, durante a qual o volume, embora ainda acessível, está em um modo degradado. Uma vez que a reconstrução esteja terminada, a array RAID está de volta ao estado normal. Pode-se então dizer ao sistema que o disco <filename>sde</filename> está para ser removido da array, para que se possa terminar com um espelhamento RAID clássico nos dois discos:

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.
pt-BR: A partir de então, a unidade pode ser fisicamente removida quando o servidor está para ser desligado, ou até mesmo removida com o sistema ligado (hot-removed) quando a configuração de hardware permite tal operação (hot-swap). Tais configurações incluem alguns controladores SCSI, a maioria dos discos SATA e unidades externas que operam com USB ou Firewire.

en: Backing up the Configuration
pt-BR: Fazendo Backup da Configuração

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:
pt-BR: Fazer uma cópia de segurança da configuração é portanto importante, mesmo que apenas para referência. A maneira padrão de fazer isso é editando o arquivo <filename>/etc/mdadm/mdadm.conf</filename>, um exemplo do que é listado aqui:

en: <command>mdadm</command> configuration file
pt-BR: <command>mdadm</command> arquivo de configuração

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.
pt-BR: Um dos detalhes mais úteis é a opção <literal>DEVICE</literal>, que lista os dispositivos aonde o sistema irá automaticamente procurar por componentes dos volumes RAID no momento da inicialização. No nosso exemplo, nós substituímos o valor padrão, <literal>partitions containers</literal>, por uma explícita lista de arquivos de dispositivos, já que nós escolhemos usar discos inteiros e não apenas partições, para alguns volumes.

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).
pt-BR: As duas últimas linhas em nosso exemplo são aquelas que permitem ao núcleo escolher, com segurança, qual número de volume atribuir a qual array. O metadado armazenado nos próprios discos são suficientes para remontar (re-assemble) os volumes, mas não para determinar o número do volume (e o nome de dispositivo que coincide com <filename>/dev/md*</filename>).

en: Fortunately, these lines can be generated automatically:
pt-BR: Felizmente, estas linhas podem ser geradas automaticamente:

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.
pt-BR: O conteúdo dessas duas últimas linhas não depende da lista de discos incluídos no volume. Logo, não é necessário regenerar essas linhas quando se for substituir um disco falho por um novo. Por outro lado, tem que se tomar o cuidado de atualizar o arquivo ao se criar ou remover uma array RAID.

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.
pt-BR: LVM, o <emphasis>Logical Volume Manager</emphasis>, é uma outra abordagem para abstrair volumes lógicos a partir de seus suportes físicos, que se concentra em aumentar a flexibilidade em vez de aumentar a confiabilidade. O LVM permite mudar um volume lógico de forma transparente, até aonde os aplicativos tem interesse ; por exemplo, é possível adicionar novos discos, migrar os dados para eles, e remover os discos velhos, sem desmontar o volume.

en: LVM Concepts
pt-BR: Conceitos sobre LVM

en: This flexibility is attained by a level of abstraction involving three concepts.
pt-BR: Esta flexibilidade é atingida graças ao nível de abstração envolvendo três conceitos.

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.
pt-BR: Primeiro, o PV (<emphasis>Physical Volume</emphasis>) é a entidade mais próxima ao hardware: ele pode ser partições em um disco, ou um disco inteiro, ou até mesmo qualquer outro dispositivo de bloco (incluindo, por exemplo, uma array RAID). Note que quando um elemento é configurado para ser um PV para o LVM, ele deveria ser acessado via LVM apenas, de outra forma o sistema irá ficar confuso.

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.
pt-BR: Vários PVs podem ser agrupados em um VG (<emphasis>Volume Group</emphasis> - Grupo de Volumes), que pode ser comparado com discos tanto virtual quanto extensível. VGs são abstratos, e não aparecem em um arquivo de dispositivo na hierarquia <filename>/dev</filename>, então não há risco em usá-los diretamente.

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).
pt-BR: O terceiro tipo de objeto é o LV (<emphasis>Logical Volume</emphasis>), que é um pedaço de um VG; se nós mantermos a analogia VG-como-disco, o LV se compara a uma partição. O LV aparece como um dispositivo de bloco com uma entrada em <filename>/dev</filename>, e ele pode ser usado como qualquer outra partição física pode ser (mais comumente, para hospedar um sistema de arquivos ou espaço swap).

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.
pt-BR: A coisa importante é que a divisão de um VG em LVs é inteiramente independente de seus componentes físicos (os PVs). Um VG com apenas um componente físico (um disco por exemplo) pode ser dividido em uma dúzia de volumes lógicos; similarmente, um VG pode usar vários discos físicos e parecer como um único e grande volume lógico. A única restrição, obviamente, é que o tamanho total alocado aos LVs não podem ser maiores que a capacidade total dos PVs no grupo de volume.

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.
pt-BR: Geralmente faz sentido, contudo, ter algum tipo de homogeneidade entre os componentes físicos de um VG, e dividir o VG em volumes lógicos que irão ter padrões de uso similares. Por exemplo, se o hardware disponível inclui discos rápidos e discos lentos, os rápidos poderiam ser agrupados em um VG e os lentos em outro; pedaços do primeiro podem então se designados para aplicações que requerem rápido acesso a dados, enquanto o segundo seria mantido para tarefas de menor demanda.

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).
pt-BR: Em todo caso, tenha em mente que um LV não está particularmente anexado a nenhum PV. É possível influenciar aonde os dados de um LV são fisicamente armazenados, mas essa possibilidade não é necessária para o uso do dia a dia. Pelo contrário: quando o conjunto de componentes físicos de um VG evolui, as localizações de armazenagem física correspondentes a um LV em particular podem ser migradas entre discos (enquanto se mantém dentro de PVs atribuídos ao VG, é claro).

en: Setting up LVM
pt-BR: Configurando um LVM

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:
pt-BR: Vamos agora seguir, passo a passo, o processo de configurar um LVM para um caso de uso típico: nós queremos simplificar uma situação complexa de armazenagem. Uma situação dessas geralmente acontece após uma longa e complicada história de medidas temporárias acumuladas. Para propósitos de ilustração, vamos considerar um servidor onde as necessidades de armazenagem alteram-se com o passar do tempo, terminando em um labirinto de partições disponíveis, divididas em vários discos parcialmente usados. Em termos mais concretos, as seguintes partições estão disponíveis:

en: on the <filename>sdb</filename> disk, a <filename>sdb2</filename> partition, 4 GB;
pt-BR: no disco <filename>sdb</filename>, uma partição <filename>sdb2</filename>, 4 GB;

en: on the <filename>sdc</filename> disk, a <filename>sdc3</filename> partition, 3 GB;
pt-BR: no disco <filename>sdc</filename>, uma partição <filename>sdc3</filename>, 3 GB;

en: the <filename>sdd</filename> disk, 4 GB, is fully available;
pt-BR: o disco <filename>sdd</filename>, 4 GB, está completamente disponível;

en: on the <filename>sdf</filename> disk, a <filename>sdf1</filename> partition, 4 GB; and a <filename>sdf2</filename> partition, 5 GB.
pt-BR: no disco <filename>sdf</filename>, uma partição <filename>sdf1</filename>, 4 GB; e uma partição <filename>sdf2</filename>, 5 GB.

en: In addition, let's assume that disks <filename>sdb</filename> and <filename>sdf</filename> are faster than the other two.
pt-BR: Complementando, vamos assumir que os discos <filename>sdb</filename> e <filename>sdf</filename> são mais rápidos do que os outros dois.

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.
pt-BR: Nosso objetivo é configurar três volumes lógicos para três diferentes aplicações: um servidor de arquivos necessitando 5 GB de espaço de armazenagem, um banco de dados (1 GB) e algum espaço para cópias de segurança (12 GB). Os dois primeiros precisam de bom desempenho, mas cópias de segurança são menos críticas em termos de velocidade de acesso. Todos essas limitações impedem o uso de partições propriamente; usando LVM pode-se abstrair o tamanho físico dos dispositivos, então o único limite é o total de espaço disponível.

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.
pt-BR: As ferramentas necessárias estão no pacote <emphasis role="pkg">lvm2</emphasis> e suas dependências. Quando os mesmos estiverem instalados, configurar o LVM terá três etapas, cobrindo três níveis de conceitos.

en: First, we prepare the physical volumes using <command>pvcreate</command>:
pt-BR: Primeiro, nós preparamos o volumes físicos utilizando <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.
pt-BR: Até agora tudo bem; note que o PV (volume físico) pode ser configurado em um disco inteiro assim como em partições individuais do mesmo. Como demonstrado acima, o comando <command>pvdisplay</command> lista os PVs existentes, com dois possíveis formatos de saída.

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.
pt-BR: Agora vamos montar esses elementos físicos em VGs usando <command>vgcreate</command>. Nós vamos reunir apenas PVs dos discos rápidos em um VG <filename>vg_critical</filename>; o outro VG, <filename>vg_normal</filename>, irá incluir também elementos mais lentos.

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.
pt-BR: Aqui novamente, os comandos são bem simples (e <command>vgdisplay</command> propõem dois formatos de saída). Note que é perfeitamente possível usar duas partições de um mesmo disco físico em dois VGs diferentes. Note também que nós usamos um prefixo <filename>vg_</filename> para nomear nossos VGs, mas isso não é nada mais que uma convenção.

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:
pt-BR: Nós agora temos dois "discos virtuais", com o tamanho de 8 GB e 12 GB respectivamente. Vamos transformá-los em "partições virtuais" (LVs). Isto envolve o comando <command>lvcreate</command> e uma sintaxe um pouco mais complexa:

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.
pt-BR: São necessários dois parâmetros para a criação de volumes lógicos; eles tem que ser passados ao <command>lvcreate</command> como opções. O nome do LV a ser criado é especificado com a opção <literal>-n</literal>, e seu tamanho geralmente é dado usando a opção <literal>-L</literal>. Nós também precisamos dizer ao comando qual o VG a ser operado, é claro, sendo portanto o último parâmetro da linha de comando.

en: <emphasis>GOING FURTHER</emphasis> <command>lvcreate</command> options
pt-BR: <emphasis>Aprofundamento</emphasis> <command>lvcreate</command> opções

en: The <command>lvcreate</command> command has several options to allow tweaking how the LV is created.
pt-BR: O comando <command>lvcreate</command> possui diversas opções que permitem manipular como o LV é criado.

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>.
pt-BR: Vamos primeiro descrever a opção <literal>-l</literal>, com a qual o tamanho do LV pode ser dados como um número de blocos (como o oposto das unidades “humanas” que nós usamos acima). Esses blocos (chamados de PEs, <emphasis>physical extents</emphasis>, nos termos LVM) são unidades contíguas de espaço de armazenamento em PVs, e elas não podem ser divididas entre LVs. Se alguém quiser definir espaço de armazenamento para um LV com alguma precisão, por exemplo para usar todo o espaço disponível, a opção <literal>-l</literal> provavelmente será preferida, ao invés da <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.
pt-BR: Também é possível sugerir uma localização física de um LV, para que suas extensões sejam armazenadas em um PV em particular (enquanto se mantém dentro dos atribuídos ao VG, é claro). Como nós sabemos que o <filename>sdb</filename> é mais rápido que o <filename>sdf</filename>, nós talvez queiramos armazenar o <filename>lv_base</filename> lá, caso nós queiramos dar uma vantagem ao servidor de banco de dados, em comparação com o servidor de arquivos. A linha de comando se torna: <command>lvcreate -n lv_base -L 1G vg_critical /dev/sdb2</command>. Note que esse comando pode falhar se o PV não tiver extensões livres suficientes. Em nosso exemplo, nós provavelmente teríamos que criar <filename>lv_base</filename> antes de <filename>lv_files</filename> para evitar essa situação – ou liberar algum espaço em <filename>sdb2</filename> com o comando <command>pvmove</command>.

en: Logical volumes, once created, end up as block device files in <filename>/dev/mapper/</filename>:
pt-BR: Volumes lógicos, quando criados, são representados como dispositivos de blocos no <filename>/dev/mapper/</filename>:

en: <emphasis>NOTE</emphasis> Auto-detecting LVM volumes
pt-BR: <emphasis>NOTA</emphasis> Autodetecção de volumes LVM

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.
pt-BR: Quando o computador é inicializado, a unidade de serviço do systemd <filename>lvm2-activation</filename> executa <command>vgchange -aay</command> para "ativar" os grupos de volume; ele faz uma busca nos dispositivos disponíveis; aqueles que tiverem sido inicializados como volumes físicos para o LVM são registrados em um subsistema LVM, aqueles que pertencem aos grupos de volume são montados, e os volumes lógicos relevantes são iniciados e disponibilizados. Não existe, portanto, necessidade de editar arquivos de configuração quando se cria ou se modifica volumes LVM.

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).
pt-BR: Note, contudo, que o layout dos elementos LVM (volumes físicos e lógicos, e grupos de volume) tem cópia de segurança em <filename>/etc/lvm/backup</filename>, que pode ser útil em caso de um problema (ou apenas para da uma espiada embaixo do capô).

en: To make things easier, convenience symbolic links are also created in directories matching the VGs:
pt-BR: Para simplificar, links simbólicos são convenientemente criados em diretórios que coincidem com os VGs:

en: The LVs can then be used exactly like standard partitions:
pt-BR: Os LVs então podem ser utilizados exatamente como partições padrão:

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.
pt-BR: Do ponto de vista das aplicações, a miríade de pequenas partições foi abstraída em um grande volume de 12 GB, com um nome amigável.

en: LVM Over Time
pt-BR: LVM ao longo do tempo

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:
pt-BR: Mesmo que a habilidade de agregar partições ou discos físicos seja conveniente, essa não é a principal vantagem trazida pelo LVM. A flexibilidade que ele trás é especialmente notada com o passar do tempo, quando as necessidades se desenvolvem. Em nosso exemplo, vamos assumir que novos e grandes arquivos tem que ser armazenados, e que o LV dedicado ao servidor de arquivos é muito pequeno para acomodá-los. Como nós não usamos todo o espaço disponível em <filename>vg_critical</filename>, nós podemos crescer o <filename>lv_files</filename>. Para esse propósito, nós iremos usar o comando <command>lvresize</command>, e então o <command>resize2fs</command> para adaptar o sistema de arquivos em conformidade:

en: <emphasis>CAUTION</emphasis> Resizing filesystems
pt-BR: <emphasis>ATENÇÃO</emphasis> Redimensionando sistemas de arquivos

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).
pt-BR: Nem todos os sistemas de arquivos podem ser redimensionados em tempo real; redimensionar um volume pode portanto requerer primeiro a desmontagem do sistema de arquivos e sua remontagem depois. Claro que, se alguém quiser diminuir o espaço alocado para um LV, o sistema de arquivos tem que ser diminuído primeiro; a ordem é revertida quando o redimensionamento segue na outra direção: o volume lógico tem que ser aumentado antes do sistema de arquivos existente nele. Isso é bastante direto, já que em nenhum momento o tamanho do sistema de arquivos deve que ser maior que o dispositivo de bloco onde ele reside (seja esse dispositivo uma partição física ou um volume lógico).

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.
pt-BR: Os sistemas de arquivo ext3, ext4 e xfs podem ser cultivados em tempo real, sem serem desmontados; encolhê-los requer uma desmontagem. O sistema de arquivos reiserfs permite o redimensionamento em tempo real nas duas direções. O venerável ext2 não permite, e sempre requer o desmonte.

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:
pt-BR: Nós poderíamos proceder de maneira similar para estender o volume que hospeda o banco de dados, apenas se nós tivermos alcançado o limite de espaço disponível do VG:

en: <emphasis>GOING FURTHER</emphasis> Advanced LVM
pt-BR: <emphasis>Aprofundamento</emphasis> LVM avançado

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.
pt-BR: O LVM também serve para usos mais avançados, aonde muitos detalhes podem ser especificados a mão. Por exemplo, um administrador pode ajustar o tamanho dos blocos que compõem os volumes físicos e lógicos, assim como seus layouts físicos. Também é possível mover blocos entre PVs, por exemplo para um ajuste fino no desempenho ou, de maneira mais mundana, liberar um PV quando alguém precisa extrair o disco físico correspondente de um VG (seja para designá-lo para outro VG ou removê-lo do LVM totalmente). As páginas de manual que descrevem os comandos geralmente são claras e detalhadas. Um bom ponto de partida é a página de manual <citerefentry><refentrytitle>lvm</refentrytitle> <manvolnum>8</manvolnum></citerefentry>.

en: RAID or LVM?
pt-BR: RAID ou 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.
pt-BR: Tanto o RAID quanto o LVM irão trazer vantagens indiscutíveis assim que se deixar o simples caso de um computador de mesa com um único disco rígido, aonde o padrão de uso não muda com o tempo. Contudo, RAID e LVM vão em direções diferentes, com objetivos divergentes, e é legítimo questionar qual deles deve ser adotado. A resposta mais apropriada irá, é claro, depender das necessidades atuais e previstas.

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.
pt-BR: Existem alguns casos simples aonde a questão realmente não surge. Se a necessidade é salvaguardar dados contra falhas de hardware, então, obviamente, o RAID será configurado em uma array redundante de discos, já que o LVM realmente não é designado para esse problema. Se, por outro lado, a necessidade é por um esquema de armazenamento flexível aonde os volumes são feitos independente do layout físico dos disco, o RAID não ajuda muito e o LVM será a escolha natural.

en: <emphasis>NOTE</emphasis> If performance matters…
pt-BR: <emphasis>NOTA</emphasis> Se o desempenho importa…

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.
pt-BR: O terceiro caso de uso notável é quando alguém apenas quer agregar dois discos em um volume, seja por questões de desempenho, ou para ter um único sistema de arquivos que seja maior que qualquer dos discos disponíveis. Esse caso pode ser resolvido pelo RAID-0 (ou mesmo um linear-RAID) e por um volume LVM. Quando nesta situação, e salvo restrições extras (por exemplo, manter em sintonia com o resto dos computadores se eles usam apenas RAID), a configuração de escolha irá geralmente ser LVM. A configuração inicial é um pouco mais complexa, mas esse incremento na complexidade mais do que compensado pela flexibilidade extra que o LVM trás caso as necessidades mudem ou se novos discos precisem ser adicionados.

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.
pt-BR: Então, é claro, temos uma caso de uso realmente interessante, aonde o sistema de armazenamento precisa ser feito tanto para resistência de falha de hardware quanto flexível quando se trata de alocação de volume. Nem RAID nem LVM podem atender esses dois requisitos por conta própria; não tem problema, é aqui que nós usamos os dois ao mesmo tempo — ou melhor, um em cima do outro. O esquema que tem tudo, mas só se tornou um padrão quando o RAID e o LVM alcançaram a maturidade, é para garantir a redundância de dados, primeiro pelo agrupamento de discos em um pequeno número de grandes arrays RAID, e para usar essas arrays RAID como volumes físicos LVM; partições lógicas serão então esculpidas a partir desses LVs para sistemas de arquivos. O ponto forte dessa configuração é que, quando um disco falha, apenas um pequeno número das arrays RAID precisará ser reconstruída, limitando assim o tempo gasto pelo administrador para recuperação.

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:
pt-BR: O RAID-1 e o LVM são combinados para satisfazer essas restrições. Os discos são anexados a duas controladoras SATA diferentes, para otimizar acesso paralelo e reduzir o risco de falhas simultâneas, e eles portanto aparecem como <filename>sda</filename> e <filename>sdc</filename>. Eles são particionados de forma idêntica, seguindo o seguinte esquema:

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.
pt-BR: Uma vez que os VGs sejam criados, eles podem ser particionados de maneira bem flexível. É preciso ter em mente que os LVs criados em <filename>vg_raid</filename> serão preservados mesmo que um dos discos falhe, o que não será o caso para LVs criados em <filename>vg_bulk</filename>; por outro lado, o último será alocado em paralelo nos dois discos, o que permite altas velocidades de leitura ou escrita para arquivos grandes.

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.
pt-BR: Portanto nós iremos criar os LVs <filename>lv_var</filename> e <filename>lv_home</filename> no <filename>vg_raid</filename>, para hospedar os sistemas de arquivos correspondentes; outro grande LV, <filename>lv_movies</filename>, será usado para hospedar as versões definitivas dos filmes após a edição. O outro VG será dividido em um grande <filename>lv_rushes</filename>, para dados vindos direto das câmeras digitais de vídeo, e um <filename>lv_tmp</filename> para arquivos temporários. A localização da área de trabalho é uma escolha menos simples de fazer: enquanto bom desempenho é necessário para esse volume, vale o risco de perda de trabalho se uma falha de disco ocorrer durante uma sessão de edição? Dependendo da resposta a essa pergunta, o LV relevante será criado em um VG ou em outro.

en: We now have both some redundancy for important data and much flexibility in how the available space is split across the applications.
pt-BR: Nós agora temos tanto alguma redundância para dados importantes quanto muita flexibilidade no modo como o espaço disponível é dividido entre as aplicações.

en: <emphasis>NOTE</emphasis> Why three RAID-1 volumes?
pt-BR: <emphasis>NOTA</emphasis> Por que três volumes RAID-1?

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?
pt-BR: Nós poderíamos ter configurado somente um volume RAID-1, para servir como volume físico para <filename>vg_raid</filename>. Por que criar três deles, então?

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.
pt-BR: A razão para a primeira divisão (<filename>md0</filename> vs. os outros) é para segurança de dados: dados escritos nos dois elementos de um espelho RAID-1 são exatamente os mesmos, e é portanto possível ignorar a camada RAID e montar um dos discos diretamente. No caso de um bug no núcleo, por exemplo, ou se os metadados do LVM forem corrompidos, ainda é possível inicializar um sistema mínimo para acessar dados críticos como o layout de discos nos volumes RAID e LVM; os metadados podem então ser reconstruídos e os arquivos podem ser acessados novamente de modo que o sistema pode ser trazido de volta ao seu estado nominal.

en: <primary>virtualization</primary>
pt-BR: <primary>virtualização</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.
pt-BR: Virtualização é um dos maiores avanços nos anos recentes da computação. O termo cobre várias abstrações e técnicas de simulação de computadores virtuais com um grau de variabilidade de independência do hardware real. Um servidor físico pode então hospedar vários sistemas que trabalham ao mesmo tempo e em isolamento. As aplicações são muitas, e geralmente derivam a partir desse isolamento: ambientes de teste com configurações variáveis por exemplo, ou separação de serviços hospedados entre diferentes máquinas virtuais para segurança.

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:
pt-BR: Existem múltiplas soluções de virtualização, cada uma com seus prós e contras. Este livro focará no Xen, LXC e KVM, mas outras implementações dignas de nota são as seguintes:

en: Bochs is another free virtual machine, but it only emulates the x86 architectures (i386 and amd64).
pt-BR: Bochs é outra máquina virtual livre, mas somente emula as arquiteturas x86 (i386 e amd64).

en: <emphasis>HARDWARE</emphasis> Virtualization support
pt-BR: <emphasis>HARDWARE</emphasis> Suporte a virtualização

en: Some computers might not have hardware virtualization support; when they do, it should be enabled in the BIOS.
pt-BR: Alguns computadores podem não possuir suporte à virtualização em hardware; quando possuem, eles deveriam ser habilitados na 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:
pt-BR: Para saber se tens ativado o suporte a virtualização, podes verificar se a opção relevante está habilitada com o <command>grep</command>. Se o seguinte comando para seu processador devolve algum texto, você tem o suporte a virtualização habilitado:

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.
pt-BR: Xen <indexterm><primary>Xen</primary></indexterm> é uma solução de “paravirtualização”. Ele introduz uma fina camada de abstração, chamada de “hypervisor”, entre o hardware e os sistemas superiores; Ele age como um árbitro que controla o acesso ao hardware feito pelas máquinas virtuais. Entretanto, ele apenas lida com algumas das instruções, o resto é executado diretamente pelo hardware em nome dos sistemas. A principal vantagem é que o desempenho não se degradada, e os sistemas rodam perto da velocidade nativa; a desvantagem é que os núcleos dos sistemas operacionais que alguém deseja usar em um "hypervisor" Xen precisam ser adaptados para rodar o 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”.
pt-BR: Vamos gastar algum tempo com termos. O "hypervisor" é a camada mais baixa, que roda diretamente no hardware, até mesmo abaixo do núcleo. Esse "hypervisor" pode dividir o resto do software entre vários <emphasis>domínios</emphasis>, que podem ser vistos como muitas máquinas virtuais. Um desses domínios (o primeiro que for iniciado) é conhecido como <emphasis>dom0</emphasis>, e tem um papel especial, já que apenas esse domínio pode controlar o "hypervisor" e a execução de outros domínios. Esses outros domínios são conhecidos como <emphasis>domU</emphasis>. Em outras palavras, e a partir do ponto de vista do usuário, o <emphasis>dom0</emphasis> coincide com o “hospedeiro” de outros sistemas de virtualização, enquanto que o <emphasis>domU</emphasis> pode ser visto como um "convidado" (“guest”).

en: <emphasis>CULTURE</emphasis> Xen and the various versions of Linux
pt-BR: <emphasis>CULTURA</emphasis> Xen e as várias versões do 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.
pt-BR: O Xen foi inicialmente desenvolvido como um conjunto de patches que viviam fora da árvore oficial, e não integrados ao núcleo Linux. Ao mesmo tempo, vários sistemas de virtualização próximos (incluindo o KVM) necessitavam de algumas funções genéricas relacionadas a virtualização para facilitar suas integrações, e o núcleo Linux ganhou esse conjunto de funções (conhecidas como interface <emphasis>paravirt_ops</emphasis> ou <emphasis>pv_ops</emphasis>). Como os patches Xen estavam duplicando algumas das funcionalidades dessa interface, eles não podiam ser aceitos oficialmente.

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" />
pt-BR: Xensource, a companhia por trás do Xen, tinha assim que portar o Xen para esse novo framework, para que os patches do Xen pudessem ser incorporados ao núcleo Linux oficial. Isso significa um monte de códigos reescritos, e embora a Xensource logo tivesse uma versão em funcionamento com base na interface paravirt_ops, os patches foram incorporados no núcleo oficial apenas progressivamente. A fusão foi concluída no Linux 3.0. <ulink type="block" url="https://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" />
pt-BR: Como a <emphasis role="distribution">Jessie</emphasis> é baseada na versão 3.16 do núcleo Linux, os pacotes padrão <emphasis role="pkg">linux-image-686-pae</emphasis> e <emphasis role="pkg">linux-image-amd64</emphasis> incluem o código necessário, e os patches específicos para <emphasis role="distribution">Squeeze</emphasis> e versões anteriores do Debian não são mais necessárias. <ulink type="block" url="https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix" />

en: <emphasis>CULTURE</emphasis> Xen and non-Linux kernels
pt-BR: <emphasis>CULTURA</emphasis> Xen e núcleos não-Linux

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" />
pt-BR: O Xen requer modificações em todos os sistemas operacionais em que se queira rodá-lo; nem todos os núcleos têm o mesmo nível de maturidade sobre esse assunto. Muitos são totalmente funcionais, tanto como dom0 quanto domU: Linux 3.0 e posteriores, NetBSD 4.0 e posteriores, e OpenSolaris. Outros apenas funcionam como domU. Você pode verificar o status de cada sistema operacional no wiki do Xen: <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).
pt-BR: Contudo, se o Xen puder contar com funções de hardware dedicadas a virtualização (que apenas estão presentes em processadores mais recentes), até mesmo sistemas operacionais não modificados podem rodar como domU (incluindo o Windows).

en: <emphasis>NOTE</emphasis> Architectures compatible with Xen
pt-BR: <emphasis>NOTA</emphasis> Arquiteturas compatíveis com Xen

en: Xen is currently only available for the i386, amd64, arm64 and armhf architectures.
pt-BR: O Xen, atualmente, só está disponível para as arquiteturas i386, amd64, arm64 e armhf.

en: Using Xen under Debian requires three components:
pt-BR: Utilizar o Xen com o Debian necessita de três componentes:

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.
pt-BR: A arquitetura i386 também requer uma biblioteca padrão com os patches apropriados para aproveitar o Xen; ela está no pacote <emphasis role="pkg">libc6-xen</emphasis>.

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.
pt-BR: Uma vez que esses pré-requisitos estejam instalados, o próximo passo é testar o comportamento do próprio dom0; isso envolve uma reinicialização do "hypervisor" e do núcleo Xen. O sistema deverá inicializar da maneira usual, com algumas mensagens extras no console, durante os passo iniciais da inicialização.

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:
pt-BR: Agora é o momento de realmente instalar sistemas úteis nos sistemas domU, usando as ferramentas do <emphasis role="pkg">xen-tools</emphasis>. esse pacote provê o comando <command>xen-create-image</command>, que automatiza a tarefa em grande parte. O único parâmetro mandatório é o <literal>--hostname</literal>, dando um nome ao domU; outras opções são importantes, mas podem ser armazenadas no arquivo de configuração <filename>/etc/xen-tools/xen-tools.conf</filename>, e assim, a ausência dessas opções na linha de comando não dispara um error. É, portanto, importante ou checar o conteúdo desse arquivo antes de criar imagens, ou usar parâmetros extras na invocação do <command>xen-create-image</command>. Parâmetros que são importantes de notar são os seguintes:

en: <literal>--memory</literal>, to specify the amount of RAM dedicated to the newly created system;
pt-BR: <literal>--memory</literal>, para definir o quantidade de RAM dedicada para o sistema recentemente criado;

en: <literal>--size</literal> and <literal>--swap</literal>, to define the size of the “virtual disks” available to the domU;
pt-BR: <literal>--size</literal> e <literal>--swap</literal>, para definir o tamanho dos "discos virtuais" disponíveis para o domU;

en: <emphasis>GOING FURTHER</emphasis> Installing a non-Debian system in a domU
pt-BR: <emphasis>Aprofundamento</emphasis> Instalando um sistema não Debian em um 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.
pt-BR: Em caso de sistemas não-Linux, um certo cuidado deve ser tomado ao definir qual domU o núcleo deve usar, usando a opção <literal>--kernel</literal>.

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.
pt-BR: <literal>--dhcp</literal> define que a configuração de rede do domU deve ser obtida por DHCP enquanto <literal>--ip</literal> permite a definição estática do endereço IP.

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.
pt-BR: Por fim, um método de armazenamento tem que ser escolhido para as imagens a serem criadas (aquelas que serão vistas como unidades de disco rígido a partir do domU). O método mais simples, que corresponde a opção <literal>--dir</literal>, é criar um arquivo no dom0 para cada dispositivo que o domU deveria fornecer. Para sistemas que usam o LVM, a alternativa é usar a opção <literal>--lvm</literal>, seguida pelo nome do grupo de volume; <command>xen-create-image</command> irá então criar um novo volume lógico dentro desse grupo, e esse volume lógico se tornará disponível para o domU como uma unidade de disco rígido.

en: <emphasis>NOTE</emphasis> Storage in the domU
pt-BR: <emphasis>NOTA</emphasis> Armazenamento em 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>.
pt-BR: Discos rígidos inteiros também podem ser exportados para o domU, assim como as partições, arrays RAID ou volumes lógicos LVM pré-existentes . Entretanto, essas operações não são automatizadas pelo <command>xen-create-image</command>. Logo, editando o arquivo de configuração de imagem do Xen irá pôr em ordem o arquivo após sua criação inicial com o <command>xen-create-image</command>.

en: Once these choices are made, we can create the image for our future Xen domU:
pt-BR: Assim que essas escolhas são feitas, podemos criar uma imagem para o nosso futuro 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.
pt-BR: Agora temos uma máquina virtual, mas atualmente não está sendo executada (e portanto somente utilizando espaço de disco do dom0). Obviamente, podemos criar mais imagens, possivelmente com parâmetros diferentes.

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:
pt-BR: Antes de ligarmos essas máquinas virtuais, nós precisamos definir como elas serão acessadas. Elas podem, é claro, serem consideradas como máquinas isoladas, apenas acessadas através de seus consoles de sistema, mas isso raramente coincide com o padrão de uso. Na maioria das vezes, um domU será considerado um servidor remoto, e apenas acessado através de uma rede. No entanto, seria bem inconveniente adicionar uma placa de rede para cada; e por isso é que o Xen permite a criação de interfaces virtuais, que cada domínio possa ver e usar da forma padrão. Note que essas interfaces, mesmo que elas sejam virtuais, só serão úteis uma vez conectadas a uma rede, mesmo que virtual. O Xen tem vários modelos de rede para isso:

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.
pt-BR: O modelo mais simples é o modelo de ponte <emphasis>bridge</emphasis>; todos as placas de rede eth0 (tanto no caso do dom0 quanto nos sistemas domU) se comportam como se fossem diretamente conectadas em um switch de rede.

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.
pt-BR: Em seguida vem o modelo <emphasis>routing</emphasis>, onde o dom0 se comporta como um roteador que se põem entre sistemas domU e a rede (física) externa.

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.
pt-BR: Finalmente, no modelo <emphasis>NAT</emphasis>, o dom0 novamente está entre os sistemas domU e o resto da rede, mas os sistemas domU não são diretamente acessíveis por fora, e todo o tráfego vai através de uma tradução de endereços de rede (NAT) para o dom0.

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.
pt-BR: Estes três nós de rede envolvem várias interfaces com nome incomuns, tais como <filename>vif*</filename>, <filename>veth*</filename>, <filename>peth*</filename> e <filename>xenbr0</filename>. O "hypervisor" Xen organiza-os de acordo com qualquer que seja o layout definido, sob o controle das ferramentas de espaço do usuário. Como o NAT e os modelos de roteamento adaptam-se apenas a casos particulares, nós só iremos abordar o modelo de "bridging".

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).
pt-BR: Após reinicializar para termos certeza de que a bridge é criada automaticamente, nós podemos iniciar o domU com as ferramentas de controle do Xen, em particular o comando <command>xl</command>. Esse comando permite diferentes manipulações nos domínios, incluindo listá-los e iniciá-los/pará-los. Você talvez precise aumentar a memória padrão, editando a variável de memória do arquivo de configuração (neste caso, <filename>/etc/xen/testxen.cfg</filename>). Aqui nós definimos para 1024 (megabytes).

en: <emphasis>TOOL</emphasis> Choice of toolstacks to manage Xen VM
pt-BR: <emphasis>FERRAMENTA</emphasis> Escolha da toolstacks para gerenciar a VM Xen

en: <emphasis>CAUTION</emphasis> Only one domU per image!
pt-BR: <emphasis>ATENÇÃO</emphasis> Somente utilize um domU por imagem!

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.
pt-BR: Enquanto é claro que é possível ter vários sistemas domU rodando em paralelo, eles todos precisarão usar suas próprias imagens, já que cada domU é feito para acreditar que ele roda em sue próprio hardware (fora a pequena parte do núcleo que conversa com o "hypervisor"). Em particular, não é possível para dois sistemas domU rodando simultaneamente, compartilhar espaço de armazenamento. Se os sistemas domU não estiverem rodando ao mesmo tempo, é, no entanto, bem possível reutilizar uma única partição de troca (swap), ou a partição de hospeda o sistema de arquivos <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.
pt-BR: Note que o <filename>testxen</filename> domU usa memória real, retirada da RAM, que estaria de outra forma disponível para o dom0, não a memória simulada. Portanto, cuidados devem ser tomados quando se constrói um servidor objetivando hospedar instâncias Xen, disponibilizando a RAM física de acordo.

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:
pt-BR: Voilà! Nossa máquina virtual está iniciando. Nós podemos acessá-la de uma de duas maneiras. A maneira usual é se conectar a ela “remotamente” através da rede, como nós nos conectaríamos a uma máquina real; isso geralmente irá requerer a configuração de um servidor DHCP ou alguma configuração de DNS. A outra maneira, que pode ser a única maneira se a configuração de rede estiver incorreta, é usar o console <filename>hvc0</filename>, com o comando <command>xl console</command>:

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.
pt-BR: Então pode-se abrir uma sessão, tal como se faria caso se estivesse sentado em frente ao teclado da máquina virtual. Desconectar-se desse console é possível através da combinação de teclas <keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo>.

en: <emphasis>TIP</emphasis> Getting the console straight away
pt-BR: <emphasis>DICA</emphasis> Obtendo o console imediatamente

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.
pt-BR: Às vezes existe o desejo de iniciar um sistema domU e ir diretamente para o seu console; é por isso que o comando <command>xl create</command> tem uma opção <literal>-c</literal>. Iniciar um domU com esse interruptor irá exibir todas as mensagens de inicialização do sistema.

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.
pt-BR: Uma vez que o domU está ativo, ele pode ser usado como qualquer outro servidor (a final de contas é um sistema GNU/Linux ). Contudo, seu status de máquina virtual permite algumas características extras. Por exemplo, um domU pode, temporariamente, ser pausado e então retomado através dos comandos <command>xl pause</command> e <command>xl unpause</command>. Note que embora um domU pausado não use qualquer recurso do processador, sua memória alocada ainda está em uso. Talvez possa ser interessante considerar os comandos <command>xl save</command> e <command>xl restore</command>: ao salvar o domU libera-se os recursos que eram usados previamente por esse domU, incluindo a RAM. Quando restaurado (ou retirado da pausa, por assim dizer), um domU não nota nada além da passagem do tempo. Se um domU estava rodando quando o dom0 é desligado,os scripts empacotados automaticamente salvam o domU, e o restaurarão na próxima inicialização. Isso irá, é claro, implicar na inconveniência padrão que ocorre quando se hiberna um computador laptop, por exemplo; em particular, se o domU é suspenso por muito tempo, as conexões de rede podem expirar. Note também que o Xen é, até agora, incompatível com uma grande parte do gerenciamento de energia do ACPI, o que impede suspensão do sistema hospedeiro (dom0).

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>.
pt-BR: Interromper ou reinicializar um domU pode ser feito tanto a partir de dentro do domU (com o comando <command>shutdown</command>) quanto a partir do dom0, com o <command>xl shutdown</command> ou <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.
pt-BR: A maioria dos subcomandos <command>xl</command> esperam um ou mais argumentos, muitas vezes um nome domU. Esses argumentos estão bem descritos na página de manual <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry>.

en: <emphasis>GOING FURTHER</emphasis> Advanced Xen
pt-BR: <emphasis>APROFUNDAMENTO</emphasis> Xen avançado

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/" />
pt-BR: O Xen tem muito mais recursos do que nós podemos descrever nesses poucos parágrafos. Em particular, o sistema é muito dinâmico, e muitos parâmetros para um domínio (como a quantidade de memoria alocada, os discos rígidos visíveis, o comportamento do agendador de tarefas, e assim por diante) podem ser ajustados até mesmo quando esse domínio está rodando. Um domU pode até mesmo ser migrado entre servidores sem ser desligado, e sem perder suas conexões de rede! Para todos esses aspectos avançados, a principal fonte de informação é a documentação oficial do Xen. <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.
pt-BR: Mesmo que seja usado para construir “máquinas virtuais”, o LXC não é, estritamente falando, um sistema de virtualização, mas um sistema que isola grupos de processos uns dos outros mesmo que eles todos rodem na mesma máquina. Ele tira proveito de um conjunto de evoluções recentes do núcleo Linux, coletivamente conhecidas como <emphasis>grupos de controle</emphasis>, de maneira que diferentes conjuntos de processos chamados de “grupos” têm diferentes visões de certos aspectos do sistema global. Os mais notáveis dentre esses aspectos são os identificadores de processo, a configuração de rede e os pontos de montagem. Tais grupos de processos isolados não terão qualquer acesso a outros processos do sistema, e esses acessos ao sistema de arquivos podem ser restritos a um subconjunto específico. Eles também podem ter sua própria interface de rede e tabela de roteamento, e também podem ser configurados para ver apenas um subconjunto de dispositivos disponíveis presentes no sistema.

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).
pt-BR: Esses recursos podem ser combinados para isolar toda uma família de processos iniciando a partir do processo <command>init</command>, e o conjunto resultante se parece muito com uma máquina virtual. O nome oficial para tal configuração é um “container” (daí o apelido LXC: <emphasis>LinuX Containers</emphasis>), mas uma diferença bastante importante com as máquinas virtuais “reais”, tais como as providas pelo Xen ou KVM é que não há um segundo núcleo; o container usa o mesmo núcleo que o sistema hospedeiro. Isso tem tanto prós quanto contras: as vantagens incluem excelente desempenho devido à total falta de sobrecarga, e o fato que o núcleo tem uma visão global de todos processos rodando no sistema, então o agendamento pode ser mais eficiente do que seria se dois núcleos independentes fossem agendar diferentes conjuntos de tarefas. O principal inconvenientes está na impossibilidade de rodar um núcleo diferente em um container (seja uma versão diferente do Linux ou um sistema operacional diferente por completo).

en: <emphasis>NOTE</emphasis> LXC isolation limits
pt-BR: <emphasis>NOTA</emphasis> limites de isolamento do LXC

en: LXC containers do not provide the level of isolation achieved by heavier emulators or virtualizers. In particular:
pt-BR: Contêineres LXC não provêm o mesmo nível de isolamento conseguido por emuladores ou virtualizadores. Em particular:

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;
pt-BR: já que o núcleo é compartilhado entre o sistema hospedeiro e os contêineres, processos restritos ao contêineres ainda podem acessar mensagens do núcleo, o qual pode levar ao vazamento de informação se as mensagem forem emitidas pelo contêiner;

en: for similar reasons, if a container is compromised and a kernel vulnerability is exploited, the other containers may be affected too;
pt-BR: por razões parecidas, se o contêiner é comprometido e se uma vulnerabilidade do núcleo é explorada, os outros contêineres podem ser afetados também;

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.
pt-BR: no sistema de arquivos, o núcleo verifica as permissões de acordo com os identificadores numéricos para usuários e grupos; esses identificadores podem designar diferentes usuários e grupos dependendo do container, o que deve ser mantido em mente se as partes com permissão de escrita do sistema de arquivos são compartilhadas entre containers.

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.
pt-BR: Como nós estamos lidando com isolamento e não virtualização simples, a criação de containers LXC é mais complexa do que simplesmente rodar o debian-installer em uma máquina virtual. Nós iremos descrever alguns pré-requisitos e, em seguida, iremos para a configuração de rede; para então depois, sermos capazes de realmente criar o sistema para ser rodado no container.

en: Preliminary Steps
pt-BR: Etapas Preliminares

en: The <emphasis role="pkg">lxc</emphasis> package contains the tools required to run LXC, and must therefore be installed.
pt-BR: O pacote <emphasis role="pkg">lxc</emphasis> contém as ferramentas necessárias para executar o LXC, e devem portanto serem instaladas.

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.
pt-BR: O LXC também necessita do sistema de configuração <emphasis>control groups</emphasis>, o qual é um sistema de arquivos virtual que é montado no <filename>/sys/fs/cgroup</filename>. Como o Debian 8 optou pelo systemd, que também faz uso de "control groups", isso agora é feito automaticamente no momento da inicialização, sem configurações adicionais.

en: Network Configuration
pt-BR: Configuração de Rede

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.
pt-BR: O objetivo de instalar o LXC é configurar máquinas virtuais; nós poderíamos, é claro, mantê-las isoladas da rede e apenas nos comunicarmos com elas através do sistema de arquivos, mas a maioria dos casos de uso envolve oferecer acesso mínimo de rede para os contêineres. No caso típico, cada contêiner terá uma interface de rede virtual conectada à rede real através de uma bridge. Essa interface virtual pode ser conectada tanto diretamente na interface de rede física do hospedeiro (e nesse caso o contêiner está diretamente na rede), ou em outra interface virtual definida no hospedeiro (e o hospedeiro pode então filtrar ou rotear o tráfego). Em ambos os casos, o pacote <emphasis role="pkg">bridge-utils</emphasis> será necessário.

en: They should be disabled and replaced with the following:
pt-BR: Devem ser desabilitados e substituídos pelo seguinte:

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.
pt-BR: O efeito dessa configuração será similar ao que seria obtido se os contêineres fossem máquinas conectadas na mesma rede física que a do hospedeiro. A configuração “bridge” gerencia o trânsito dos quadros Ethernet entre todas as interfaces em bridge, o que inclui a <literal>eth0</literal> física, assim como as interfaces definidas para os contêineres.

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.
pt-BR: Em casos onde essa configuração não pode ser usada (por exemplo, se nenhum endereço IP público pode ser atribuído aos containers), uma interface virtual <emphasis>tap</emphasis> será criada e conectada à brigde. A topologia de rede equivalente torna-se então de um host com uma segunda placa de rede conectada em um switch separado, com os containers também conectados nesse switch. O host tem então que atuar como um gateway para os containers caso eles sejam feitos para se comunicar com o mundo exterior.

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:
pt-BR: Em adição ao <emphasis role="pkg">bridge-utils</emphasis>, essa “rica” configuração requer o pacote <emphasis role="pkg">vde2</emphasis>; o arquivo <filename>/etc/network/interfaces</filename> então torna-se:

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.
pt-BR: A rede então pode ser configurada tanto estaticamente nos contêineres, quanto dinamicamente com um servidor DHCP rodando no host. Tal servidor DHCP deverá ser configurado para responder as consultas na interface <literal>br0</literal>.

en: Setting Up the System
pt-BR: Configurando o Sistema

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.
pt-BR: Note que o sistema de arquivo é inicialmente criado em <filename>/var/cache/lxc</filename>, então é movido para o seu diretório de destino. Isto proporciona a criação de contêineres idênticos mais rapidamente, já que somente um cópia é necessária.

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.
pt-BR: Note que o script de criação de modelo do Debian aceita uma opção <option>--arch</option> para especificar a arquitetura do sistema a ser instalado e uma opção <option>--release</option> caso você queira instalar alguma coisa a mais que a atual versão estável do Debian. Você pode também definir a variável de ambiente <literal>MIRROR</literal> para apontar para um espelho Debian local.

en: Another useful entry in that file is the setting of the hostname:
pt-BR: Outra entrada útil nesse arquivo é a configuração de uma nome para o hospedeiro:

en: Starting the Container
pt-BR: Inicializando o Contêiner

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>.
pt-BR: Nós agora estamos dentro do container; nosso acesso aos processos é restrito apenas aqueles que foram iniciados a partir do próprio container, e nosso acesso ao sistema de arquivos é similarmente restrito ao subconjunto do sistema de arquivos completo dedicado (<filename>/var/lib/lxc/testlxc/rootfs</filename>). Nós podemos sair do console com <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.
pt-BR: O pacote <emphasis role="pkg">lxc</emphasis> contém um script de inicialização que pode iniciar automaticamente um ou vários containers quando a máquina inicia (ele faz uso do <command>lxc-autostart</command> que inicia os containers que tem a opção <literal>lxc.start.auto</literal> definida como 1). Controle mais afinado da ordem de início é possível com <literal>lxc.start.order</literal> e <literal>lxc.group</literal>: por padrão, o script de inicialização primeiro inicia os containers que são parte do grupo <literal>onboot</literal> e então os containers que não fazem parte de nenhum grupo. Em ambos os casos, a ordem dentro de um grupo é definida pela opção <literal>lxc.start.order</literal>.

en: <emphasis>GOING FURTHER</emphasis> Mass virtualization
pt-BR: <emphasis>APROFUNDAMENTO</emphasis> Virtualização em massa

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.
pt-BR: Como o LXC é um sistema de isolamento muito leve, pode ser particularmente adaptado par uma maciça hospedagem de servidores virtuais. A configuração de rede provavelmente será um pouco mais avançada do que aquela que descrevemos acima, mas a configuração “rica”, usando as interfaces <literal>tap</literal> e <literal>veth</literal>, deverá ser suficiente em muitos casos.

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.
pt-BR: Também pode fazer sentido compartilhar parte do sistema de arquivos, como os subdiretórios <filename>/usr</filename> e <filename>/lib</filename>, a fim de evitar a duplicação de software que possa ser comum a vários containers. Isso irá, geralmente, ser alcançado com as entradas <literal>lxc.mount.entry</literal> no arquivo de configuração dos containers. Um interessante efeito colateral é que os processos irão então usar menos memória física, já que o núcleo é capaz de detectar que os programas são compartilhados. O custo marginal de um container extra pode então ser reduzido a espaço de disco dedicado para seus dados específicos, e alguns processos extras que o núcleo tem que agendar e gerenciar.

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.
pt-BR: Nós não descrevemos todas as opções disponíveis, é claro; informações mais completas podem ser obtidas a partir das páginas de manual <citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry> e <citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> e aquelas que elas referenciam.

en: Virtualization with KVM
pt-BR: Virtualização com KVM

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.
pt-BR: KVM, que significa <emphasis>Kernel-based Virtual Machine</emphasis>, é primeiro e antes de tudo um módulo do núcleo que fornece a maior parte da infraestrutura que pode ser usada por um virtualizador, mas não um virtualizador em si mesmo. O controle real para virtualização é tratado por um aplicativo com base no QEMU. Não se preocupe se essa seção menciona os comandos <command>qemu-*</command>: ela continua sendo sobre 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>.
pt-BR: Ao contrário de outros sistemas de virtualização, o KVM foi incorporado ao núcleo Linux desde o seu início. Seus desenvolvedores escolheram tirar vantagem do conjunto de instruções do processador dedicado a virtualização (Intel-VT e AMD-V), o que mantém o KVM leve, elegante e sem fome por recursos. A contraparte, claro, é que o KVM não funciona em qualquer computador, mas apenas naqueles com os processadores apropriados. Para computadores baseados em x86, você pode verificar que você tem tal processador procurando por “vmx” ou “svm” nas flags da CPU listadas em <filename>/proc/cpuinfo</filename>.

en: With Red Hat actively supporting its development, KVM has more or less become the reference for Linux virtualization.
pt-BR: Com a Red Hat ativamente suportando seu desenvolvimento, o KVM se tornou mais ou menos a referência na virtualização do Linux.

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.
pt-BR: Nós primeiro instalamos os pacotes necessários, com <command>apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer</command>. O <emphasis role="pkg">libvirt-daemon-system</emphasis> fornece o daemon <command>libvirtd</command>, que permite o gerenciamento (potencialmente remoto) de máquinas virtuais rodando no host, e inicia as VMs necessárias quando o host inicializa. O pacote <emphasis role="pkg">libvirt-clients</emphasis> fornece a ferramenta de linha de comando <command>virsh</command>, que permite o controle das máquinas gerenciadas pelo <command>libvirtd</command>.

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.
pt-BR: O pacote <emphasis role="pkg">virtinst</emphasis> fornece o <command>virt-install</command>, o qual permite a criação de máquinas virtuais a partir da linha de comando. E finalmente, o <emphasis role="pkg">virt-viewer</emphasis> que permite o acessar o console gráfico das VM's.

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" />).
pt-BR: Assim como no Xen e no LXC, a configuração de rede mais frequente envolve uma bridge agrupando as interfaces de rede das máquinas virtuais (veja <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.
pt-BR: Alternativamente, e na configuração padrão fornecida pelo KVM, um endereço privado é atribuído a máquina virtual (no intervalo 192.168.122.0/24), e o NAT é configurado para que a VM possa acessar a rede externa.

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.
pt-BR: O restante desta seção assume que o host tem uma interface física <literal>eth0</literal> e uma bridge <literal>br0</literal>, e que a primeira está conectada a última.

en: Installation with <command>virt-install</command>
pt-BR: Instalação com <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.
pt-BR: A criação de uma máquina virtual é muito similar a instalação de um sistema normal, exceto que as características da máquina virtual são descritas em uma linha de comando aparentemente interminável.

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.
pt-BR: Em termos práticos, isso significa que nós iremos usar o instalador Debian, inicializando a máquina virtual pelo drive DVD-ROM virtual que é mapeado para uma imagem de DVD do Debian armazenada no sistema do host. A VM irá exportar seu console gráfico pelo protocolo VNC (see <xref linkend="sect.remote-desktops" /> for details), o que irá nos permitir controlar o processo de instalação.

en: <emphasis>TIP</emphasis> Add your user to the libvirt group
pt-BR: <emphasis>DICA</emphasis> Adicione seu usuário ao grupo libvirt

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.
pt-BR: Todos os exemplos nesta seção assumem que você está executando comandos como root. Efetivamente, se você quer controlar um serviço ("daemon") libvirt local, você precisa ser root ou ser membro do grupo <literal>libvirt</literal> (o que por padrão não é o caso). Assim, se você quer evitar ficar usando direitos de root com frequência, você pode adicionar a si próprio ao grupo <literal>libvirt</literal> e rodar os vários comandos com a identidade de seu usuário(a).

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.
pt-BR: Vamos agora iniciar o processo de instalação da máquina virtual, e ter um olhar mais atento nas mais importantes opções do <command>virt-install</command>. Esse comando registra a máquina virtual e seus parâmetros no libvirtd, e então, a inicia, para que a sua instalação possa prosseguir.

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>).
pt-BR: A opção <literal>--connect</literal> especifica o “hypervisor” a ser usado. Sua forma é a de uma URL contendo o sistema de virtualização (<literal>xen://</literal>, <literal>qemu://</literal>, <literal>lxc://</literal>, <literal>openvz://</literal>, <literal>vbox://</literal>, e assim por diante) e a máquina que deve hospedar a VM (isso pode ser deixado vazio, no caso de ser um hospedeiro local). Além disso, no caso do QEMU/KVM, cada usuário pode gerenciar máquinas virtuais trabalhando com permissões restritas, e o caminho da URL permite diferenciar máquinas do “sistema” (<literal>/system</literal>) de outras (<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.
pt-BR: Como o KVM é gerenciado da mesma maneira que o QEMU, o <literal>--virt-type kvm</literal> permite especificar o uso do KVM, mesmo que a URL se pareça com a do QEMU.

en: The <literal>--name</literal> option defines a (unique) name for the virtual machine.
pt-BR: A opção <literal>--name</literal> define um nome (específico) para a máquina virtual.

en: The <literal>--memory</literal> option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.
pt-BR: A opção <literal>--memory</literal> permite especificar a quantidade de RAM (em MB) a ser alocada para a máquina virtual.

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.
pt-BR: A <literal>--disk</literal> especifica a localização do arquivo de imagem que irá representar nosso disco rígido da máquina virtual; esse arquivo é criado, se não estiver presente, com tamanho(em GB) especificado pelo parâmetro <literal>size</literal>. O parâmetro <literal>format</literal> permite escolher entre as várias maneiras de se armazenar o arquivo de imagem. O formato padrão (<literal>qcow2</literal>) permite iniciar com um pequeno arquivo que só cresce quando a máquina virtual realmente começa a usar espaço.

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>).
pt-BR: A opção <literal>--cdrom</literal> é usada para indicar aonde encontrar o disco ótico para usar na instalação. O caminho pode ser tanto um caminho local para um arquivo ISO, uma URL aonde o arquivo pode ser obtido, ou um arquivo de dispositivo de um drive físico de CD-ROM (por exemplo <literal>/dev/cdrom</literal>).

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).
pt-BR: A <literal>--network</literal> especifica como a placa de rede virtual se integra na configuração de rede do hospedeiro. O comportamento padrão (o qual nós explicitamente forçamos em nosso exemplo) é para integrá-la em qualquer bridge de rede pré-existente. Se tal bridge não existe, a máquina virtual irá apenas alcançar a rede física através de NAT, ficando em um intervalo de endereço da sub-rede privada (192.168.122.0/24).

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.
pt-BR: <literal>--vnc</literal> determina que o console gráfico de ser disponibilizado usando o VNC. O comportamento padrão para o servidor VNC associado é para apenas escutar na interface local; se um cliente VNC tiver que ser executado em um host diferente, para estabelecer a conexão será necessário a configuração de um túnel SSH (veja <xref linkend="sect.ssh-port-forwarding" />). Alternativamente, <literal>--graphics vnclisten=0.0.0.0</literal> pode ser usada para que o servidor VNC seja acessível a partir de todas as interfaces; note que se você fizer isso, você realmente deve projetar seu firewall de maneira apropriada.

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.
pt-BR: As opções <literal>--os-type</literal> e <literal>--os-variant</literal> permitem a otimização de alguns parâmetros de máquina virtual, com base em algumas das conhecidas características do sistema operacional ali mencionadas.

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):
pt-BR: Nesse ponto, a máquina virtual está rodando, e nós precisamos nos conectar ao console gráfico para prosseguir com o processo de instalação. Se a operação prévia foi executada a partir de um ambiente gráfico, essa conexão deve ser iniciada automaticamente. Se não, ou se nós operamos remotamente, o <command>virt-viewer</command> pode ser rodado a partir de qualquer ambiente gráfico para abrir o console gráfico (note que a senha do root do host remoto é pedida duas vezes porque a operação requer 2 conexões SSH):

en: When the installation process ends, the virtual machine is restarted, now ready for use.
pt-BR: Quando o processo de instalação terminar, a máquina virtual é reiniciada, e agora pronta para o uso.

en: Managing Machines with <command>virsh</command>
pt-BR: Gerenciando Máquina com <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:
pt-BR: Agora que instalação está feita, vamos ver como lidar com as máquinas virtuais disponíveis. A primeira coisa a tentar é pedir ao <command>libvirtd</command> a lista de máquinas virtuais que ele gerencia:

en: Let's start our test virtual machine:
pt-BR: Vamos iniciar nossa máquina virtual de teste:

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>):
pt-BR: Nós podemos agora pegar as instruções de conexão para o console gráfico (o visor VNC retornado pode ser dado como parâmetro para o <command>vncviewer</command>):

en: Other available <command>virsh</command> subcommands include:
pt-BR: Outros subcomandos disponíveis para o <command>virsh</command> incluem:

en: <literal>reboot</literal> to restart a virtual machine;
pt-BR: <literal>reboot</literal> reinicia uma máquina virtual;

en: <literal>shutdown</literal> to trigger a clean shutdown;
pt-BR: <literal>shutdown</literal> para ativar um desligamento limpo;

en: <literal>destroy</literal>, to stop it brutally;
pt-BR: <literal>destroy</literal>, para parar abruptamente;

en: <literal>suspend</literal> to pause it;
pt-BR: <literal>suspend</literal> para pausar a mesma;

en: <literal>resume</literal> to unpause it;
pt-BR: <literal>resume</literal> para despausar a mesma;

en: <literal>autostart</literal> to enable (or disable, with the <literal>--disable</literal> option) starting the virtual machine automatically when the host starts;
pt-BR: <literal>autostart</literal> para habilitar (ou desabilitar, com a opção <literal>--disable</literal>) o início da máquina virtual automaticamente quando o hospedeiro é iniciado;

en: <literal>undefine</literal> to remove all traces of the virtual machine from <command>libvirtd</command>.
pt-BR: <literal>undefine</literal> para remover todos os registros de uma máquina virtual do <command>libvirtd</command>.

en: All these subcommands take a virtual machine identifier as a parameter.
pt-BR: Todos esses subcomandos têm como parâmetro a identificação da máquina virtual.

en: Automated Installation
pt-BR: Instalação Automatizada

en: <primary>deployment</primary>
pt-BR: <primary>implantação</primary>

en: <primary>installation</primary><secondary>automated installation</secondary>
pt-BR: <primary>instalação</primary><secondary>instalação automatizada</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.
pt-BR: Os administradores da Falcot Corp, como muitos administradores de grandes serviços de TI, precisam de ferramentas para instalar (ou reinstalar) rapidamente, e automaticamente se possível, suas novas máquinas.

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).
pt-BR: Essas exigências podem ser atendidas por uma ampla gama de soluções. Por um lado, ferramentas genéricas como a SystemImager lidam com isso criando uma imagem baseada em uma máquina modelo, e então, implantam essa imagem nos sistemas alvo; no extremo oposto do espectro, o instalador Debian padrão pode ser pré alimentado com um arquivo de configuração contendo as repostas das questões perguntadas durante o processo de instalação. Como um tipo de meio termo, uma ferramenta híbrida como a FAI (<emphasis>Fully Automatic Installer</emphasis>) instala máquinas usando o sistema de empacotamento, mas ela também usa sua própria infraestrutura para tarefas que são mais específicas para implantações em massa (como iniciação, particionamento, configuração e assim por diante).

en: Fully Automatic Installer (FAI)
pt-BR: Instalador Completamente Automático (FAI)

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.
pt-BR: <foreignphrase>Instalador Completamente Automático (Fully Automatic Installer)</foreignphrase> é provavelmente o mais antigo sistema de implantação automatizada para Debian, o que explica seu status como uma referência; mas sua natureza muito flexível apenas compensa a complexidade que ele envolve.

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).
pt-BR: O FAI requer um sistema de servidor para armazenar informação da implantação e permitir que as máquinas alvo inicializem a partir da rede. Esse servidor requer o pacote <emphasis role="pkg">fai-server</emphasis> (ou <emphasis role="pkg">fai-quickstart</emphasis>, que também traz os elementos necessários para uma configuração padrão).

en: Creating all these configuration files requires some understanding of the way FAI works. A typical installation process is made of the following steps:
pt-BR: Para criar todos esses arquivos de configuração é necessário algum entendimento da maneira a qual o FAI funciona. Um processo de instalação típico é feito dos passos seguintes:

en: fetching a kernel from the network, and booting it;
pt-BR: pegar um núcleo da rede, e iniciá-lo;

en: mounting the root filesystem from NFS;
pt-BR: montar um sistema de arquivo raiz de um NFS;

en: executing <command>/usr/sbin/fai</command>, which controls the rest of the process (the next steps are therefore initiated by this script);
pt-BR: executar <command>/usr/sbin/fai</command>, o qual controla o resto do processo (os próximos passos portanto são iniciados por este roteiro);

en: copying the configuration space from the server into <filename>/fai/</filename>;
pt-BR: copiar o espaço de configuração do servidor para <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.
pt-BR: rodando <command>fai-class</command>. Os scripts <filename>/fai/class/[0-9][0-9]*</filename> são executados em turnos, e retornam nomes de “classes” que se aplicam a máquina que está sendo instalada; essa informação irá servir como base para as etapas seguintes. Isso permite alguma flexibilidade na definição de serviços a serem instalados e configurados.

en: fetching a number of configuration variables, depending on the relevant classes;
pt-BR: buscando várias variáveis de configuração, dependendo das classes relevantes;

en: partitioning the disks and formatting the partitions, based on information provided in <filename>/fai/disk_config/<replaceable>class</replaceable></filename>;
pt-BR: particionar os discos e formatar as partições com base nas informações fornecidas em <filename>/fai/disk_config/<replaceable>class</replaceable></filename>;

en: mounting said partitions;
pt-BR: montar essas partições;

en: installing the base system;
pt-BR: instalar o sistema base;

en: preseeding the Debconf database with <command>fai-debconf</command>;
pt-BR: preparar o banco de dados Debconf com <command>fai-debconf</command>;

en: fetching the list of available packages for APT;
pt-BR: buscar a lista de pacotes disponíveis para o APT;

en: installing the packages listed in <filename>/fai/package_config/<replaceable>class</replaceable></filename>;
pt-BR: instalar os pacotes listados em <filename>/fai/package_config/<replaceable>class</replaceable></filename>;

en: executing the post-configuration scripts, <filename>/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename>;
pt-BR: executar os scripts de pós configuração, <filename>/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename>;

en: recording the installation logs, unmounting the partitions, and rebooting.
pt-BR: gravar os registros de instalação, desmontar as partições e reinicializar o computador.

en: <primary>preconfiguration</primary>
pt-BR: <primary>pré-configuração</primary>

en: <emphasis>GOING FURTHER</emphasis> Debconf with a centralized database
pt-BR: <emphasis>INDO ALÉM</emphasis> Debconf com um banco de dados centralizado

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).
pt-BR: O Preseeding permite fornecer um conjunto de respostas às perguntas do Debconf no momento da instalação, mas essas respostas são estáticas e não evoluem com o passar do tempo. Como máquinas já instaladas talvez precisem de atualização, e novas respostas talvez venham a ser necessárias, o arquivo de configuração <filename>/etc/debconf.conf</filename> pode ser configurado para que o Debconf use fontes de dados externas (como um servidor de diretório LDAP, ou um arquivo remoto acessado via NFS ou Samba). Várias fontes de dados externas podem ser definidas ao mesmo tempo, e elas se complementam. O banco de dados local ainda é usado (para acesso leitura-escrita), mas os bancos de dados remotos são, geralmente, restritos a leitura. A página de manual <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> descreve todas as possibilidades em detalhes. (você precisa do pacote <emphasis role="pkg">debconf-doc</emphasis>).

en: Using a Preseed File
pt-BR: Usando um Arquivo Preseed

en: There are several places where the installer can get a preseeding file:
pt-BR: Existem vários lugares aonde o instalador pode obter um arquivo preseeding:

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.
pt-BR: Dentro do initrd ,usado para iniciar a máquina; neste caso, o preseeding acontece bem no início da instalação, e todas as perguntas podem ser evitadas. O arquivo apenas precisa ser chamado <filename>preseed.cfg</filename> e armazenado dentro da raiz do initrd.

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).
pt-BR: na mídia de inicialização (CD ou dispositivo USB); o preseeding então acontece assim que a mídia é montada, o que significa ser logo após as perguntas sobre idioma e layout do teclado. O parâmetro de inicialização <literal>preseed/file</literal> pode ser usado para indicar a localização do arquivo preseeding (por exemplo, <filename>/cdrom/preseed.cfg</filename> quando a instalação é feita por um CD-ROM, ou <filename>/hd-media/preseed.cfg</filename> no caso de um dispositivo USB).

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).
pt-BR: De relance, incluir o arquivo preseeding dentro do initrd parece ser a solução mais interessante; no entanto, ela raramente é usada na prática, porque gerar um initrd instalador é bem complexo. As outras duas soluções são muito mais comuns, especialmente quando os parâmetros de inicialização fornecem outra maneira de fazer "preseed" das respostas para as primeiras perguntas do processo de instalação. A maneira usual de evitar o incômodo de digitar esses parâmetro de inicialização a manualmente a cada instalação é salvá-los na configuração do <command>isolinux</command> (no caso do CD-ROM) ou <command>syslinux</command> (dispositivo USB).

en: Creating a Preseed File
pt-BR: Criando um Arquivo Preseed

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>:
pt-BR: Um arquivo preseed é um arquivo de texto puro, aonde cada linha contém a resposta para uma pergunta do Debconf. A linha é dividida em quatro campos separados por espaço em branco (espaços ou tabs), com em, por exemplo, <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;
pt-BR: o primeiro campo é o “dono” da pergunta; “d-i” é usado para perguntas relevantes para o instalador, mas ele também pode ser um nome de pacote para perguntas vindas a partir de pacotes Debian;

en: third, the type of question;
pt-BR: terceiro, o tipo de pergunta;

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.
pt-BR: o quarto e último campo contém o valor para a resposta. Note que ele tem que ser separador do terceiro campo com um único espaço; se existir mais de um, os caracteres espaço seguintes serão considerados parte do valor.

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.
pt-BR: A maneira mais simples de escrever um arquivo preseed é instalar o sistema manualmente. Então o <command>debconf-get-selections --installer</command> irá prover as respostas com relação ao instalador. Respostas sobre outros pacotes podem ser obtidas com <command>debconf-get-selections</command>. No entanto, uma solução mais limpa é escrever o arquivo preseed manualmente, iniciando a partir de um exemplo e da documentação de referência: com tal abordagem, apenas perguntas aonde a resposta padrão precisa ser sobrescrita podem se submeter ao preseeded; usando o parâmetro de inicialização <literal>priority=critical</literal> irá instruir o Debconf a apenas perguntar questões criticas, e usar a resposta padrão para as outras.

en: <emphasis>DOCUMENTATION</emphasis> Installation guide appendix
pt-BR: <emphasis>DOCUMENTAÇÃO</emphasis> Apêndice do guia de instalação

en: Creating a Customized Boot Media
pt-BR: Criando uma Mídia de Inicialização Customizada

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.
pt-BR: Saber aonde armazenar um arquivo preseed é muito bom, mas a localização não é tudo: é preciso, de uma forma ou de outra, alterar a mídia de inicialização de instalação para mudar os parâmetros de inicialização e adicionar o arquivo preseed.

en: Booting From the Network
pt-BR: Inicializando a Partir da Rede

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" />
pt-BR: Quando um computador é inicializado a partir da rede, o servidor que envia os elementos de inicialização também define os parâmetros de inicialização. Assim, a alteração precisa ser feita na configuração PXE do servidor de inicialização; mais especificamente, no seu arquivo de configuração <filename>/tftpboot/pxelinux.cfg/default</filename>. Configurar a inicialização pela rede é um pré-requisito; veja o Guia de Instalação para detalhes. <ulink type="block" url="https://www.debian.org/releases/stable/amd64/ch04s05" />

en: Preparing a Bootable USB Key
pt-BR: Preparando um Dispositivo USB Inicializável

en: syslinux.cfg file and preseeding parameters
pt-BR: arquivo syslinux.cfg e parâmetros preseeding

en: Creating a CD-ROM Image
pt-BR: Criando uma Imagem de CD-ROM

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.
pt-BR: Um dispositivo USB é uma mídia de leitura-escrita, então foi fácil para nós adicionar um arquivo lá e alterar alguns parâmetros. No caso do CD-ROM, a operação é mais complexa, já que nós precisamos refazer uma imagem ISO completa. Essa tarefa é feita pelo <emphasis role="pkg">debian-cd</emphasis>, mas essa ferramenta é um pouco mais complicada de usar: ela precisa de um espelho local, e requer o entendimento de todas as opções fornecidas pelo <filename>/usr/share/debian-cd/CONF.sh</filename>; mesmo assim, o <command>make</command> tem que ser invocado várias vezes. <filename>/usr/share/debian-cd/README</filename> é, portanto, uma leitura muito recomendada.

en: Simple-CDD: The All-In-One Solution
pt-BR: Simple-CDD: A Solução Tudo-Em-Um

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.
pt-BR: Simplesmente usar um arquivo preseed não é o suficiente para preencher todos os requerimentos que possam aparecer em grandes implantações. Mesmo que seja possível executar alguns scripts no final de processos normais de instalação, a seleção de um conjunto de pacotes a instalar ainda não é muito flexível (basicamente, apenas “tarefas” podem ser selecionadas); mais importante, isso apenas permite a instalação de pacotes Debian oficiais e impede os gerados localmente.

en: Creating Profiles
pt-BR: Criando Perfis

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:
pt-BR: O Simple-CDD define “perfis” que coincidem com o conceito “classes” FAI e uma máquina pode ter vários perfis (determinados no momento da instalação). Um perfil é definido por um conjunto de arquivos <filename>profiles/<replaceable>profile</replaceable>.*</filename>:

en: the <filename>.description</filename> file contains a one-line description for the profile;
pt-BR: o arquivo <filename>.description</filename> contém uma descrição de uma linha para o perfil;

en: the <filename>.packages</filename> file lists packages that will automatically be installed if the profile is selected;
pt-BR: o arquivo <filename>.packages</filename> lista os pacotes que irão ser instalados automaticamente caso o perfil seja selecionado;

en: the <filename>.downloads</filename> file lists packages that will be stored onto the installation media, but not necessarily installed;
pt-BR: o arquivo <filename>.downloads</filename> lista os pacotes que serão armazenados na mídia de instalação, mas não necessariamente instalados;

en: the <filename>.preseed</filename> file contains preseeding information for Debconf questions (for the installer and/or for packages);
pt-BR: o arquivo <filename>.preseed</filename> contém as informações preseeding para as perguntas do Debconf (para o instalador e/ou para os pacotes);

en: the <filename>.postinst</filename> file contains a script that will be run at the end of the installation process;
pt-BR: o arquivo <filename>.postinst</filename> contém um script que será executado no final do processo de instalação;

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.
pt-BR: O perfil <literal>padrão</literal> tem uma função em particular, já que ele está sempre selecionado; el contém o mínimo necessário para o Simple-CDD funcionar. A única coisa que geralmente é customizada nesse perfil é o parâmetro preseed <literal>simple-cdd/profiles</literal>: isso permite evitar a pergunta, introduzida pelo Simple-CDD, sobre quais perfis instalar.

en: Note also that the commands will need to be invoked from the parent directory of the <filename>profiles</filename> directory.
pt-BR: Note também que os comandos precisam ser invocados a partir do diretório pai do diretório <filename>profiles</filename>.

en: Configuring and Using <command>build-simple-cdd</command>
pt-BR: Configurando e Usando o <command>build-simple-cdd</command>

en: <emphasis>QUICK LOOK</emphasis> Detailed configuration file
pt-BR: <emphasis>OLHADA RÁPIDA</emphasis> Arquivo de configuração detalhado

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:
pt-BR: O Simple-CDD requer muitos parâmetros para operar plenamente. Eles irão, na maioria das vezes, estar reunidos em um arquivo de configuração, o qual pode ser informado ao <command>build-simple-cdd</command> com a opção <literal>--conf</literal>, mas eles também podem ser especificados via parâmetros dedicados dados ao <command>build-simple-cdd</command>. Aqui está uma visão geral de como esse comando se comporta, e como seus parâmetros são usados:

en: the <literal>profiles</literal> parameter lists the profiles that will be included on the generated CD-ROM image;
pt-BR: o parâmetro <literal>profiles</literal> lista os perfis que serão incluídos na imagem CD-ROM gerada;

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);
pt-BR: com base na lista de pacotes requeridos, o Simple-CDD baixa os arquivos apropriados do servidor mencionado em <literal>server</literal>, e os reúne em um espelho parcial (que mais tarde será dado ao debian-cd);

en: the custom packages mentioned in <literal>local_packages</literal> are also integrated into this local mirror;
pt-BR: os pacotes customizados mencionados em <literal>local_packages</literal> também são integrados neste espelho local;

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;
pt-BR: o debian-cd é então executado (dentro de uma local padrão que pode ser configurada com a variável <literal>debian_cd_dir</literal>), com a lista de pacotes para integrar;

en: once debian-cd has prepared its directory, Simple-CDD applies some changes to this directory:
pt-BR: uma vez que o debian-cd tenha preparado seu diretório, o Simple-CDD aplica algumas mudanças nesse diretório:

en: files containing the profiles are added in a <filename>simple-cdd</filename> subdirectory (that will end up on the CD-ROM);
pt-BR: arquivos contendo os perfis são adicionados em um subdiretório <filename>simple-cdd</filename> (que irá terminar no CD-ROM);

en: other files listed in the <literal>all_extras</literal> parameter are also added;
pt-BR: outros arquivos listados no parâmetro <literal>all_extras</literal> também são adicionados;

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.
pt-BR: os parâmetros de inicialização são ajustados a fim de habilitar o preseeding. Perguntas com relação a idioma e país podem ser evitadas se a informação requerida está armazenada nas variáveis <literal>language</literal> e <literal>country</literal>.

en: debian-cd then generates the final ISO image.
pt-BR: o debian-cd então gera a imagem ISO final.

en: Generating an ISO Image
pt-BR: Gerando uma imagem ISO

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.
pt-BR: O monitoramento é um termo genérico e as várias atividades envolvidas tem vários objetivos: por um lado, seguir o uso dos recursos fornecidos pela máquina permite antecipar a saturação e os subsequentes necessidades de upgrades; por outro lado, alertar o administrador assim que um serviço fica indisponível ou não está funcionando de maneira apropriada significa que os problemas que estão acontecendo podem ser consertados mais rapidamente.

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.
pt-BR: O <emphasis>Munin</emphasis> cobre a primeira área, exibindo gráficos de valores históricos de inúmeros parâmetros (RAM usada, espaço de disco ocupado, carga do processador, tráfego de rede,carga do Apache/MySQL, e assim por diante). O <emphasis>Nagios</emphasis> cobre a segunda área,regularmente checando se os serviços estão funcionando e disponíveis, e enviando alertas através dos canais apropriados (e-mails, mensagens de texto e assim por diante). Os dois tem um design modular, o que torna fácil criar novas extensões para monitorar parâmetros específicos ou serviços.

en: <emphasis>ALTERNATIVE</emphasis> Zabbix, an integrated monitoring tool
pt-BR: <emphasis>ALTERNATIVA</emphasis> Zabbix, uma ferramenta de monitoramento integrada

en: <emphasis>ALTERNATIVE</emphasis> Icinga, a Nagios fork
pt-BR: <emphasis>ALTERNATIVA</emphasis> Icinga, uma ramificação do Nagios

en: Setting Up Munin
pt-BR: Configurando o 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.
pt-BR: O propósito do Munin é monitorar muitas máquinas; logo, é bem natural que ele use uma arquitetura cliente/servidor. A máquina ("host") central — que faz o gráfico ("grapher") — coleta dados de todas as máquinas ("hosts") monitoradas, e gera gráficos com os históricos.

en: Configuring Hosts To Monitor
pt-BR: Configurando As Máquinas A Serem Monitoradas

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.
pt-BR: O primeiro passo é instalar o pacote <emphasis role="pkg">munin-node</emphasis>. O serviço ("daemon") instalado por esse pacote escuta na porta 4949 e envia de volta os dados coletados por todas as extensões ativas. Cada extensão é um programa simples que retorna um descrição dos dados coletados, assim como o último valor medido. As extensões são armazenadas em <filename>/usr/share/munin/plugins/</filename>, mas apenas aquelas com uma ligação simbólica em <filename>/etc/munin/plugins/</filename> são realmente usadas.

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>.
pt-BR: Uma vez que todas as extensões estejam configuradas corretamente, a configuração do serviço ("daemon") tem que ser atualizada para descrever o controle de acesso aos dados coletados. Isso envolve a diretiva <literal>allow</literal> no arquivo <filename>/etc/munin/munin-node.conf</filename>. A configuração padão é <literal>allow ^127\.0\.0\.1$</literal>, e apenas permite acesso à máquina local. Um administrador geralmente irá adicionar uma linha similar contendo o endereço IP da máquina que gera o gráfico ("grapher host"), e então reiniciar o serviço com <command>systemctl restart munin-node</command>.

en: <emphasis>GOING FURTHER</emphasis> Creating local plugins
pt-BR: <emphasis>APROFUNDANDO</emphasis> Criando extensões locais

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.
pt-BR: Uma extensão é melhor testada quando executada nas mesmas condições encontradas quando iniciada pelo munin-node; isso pode ser simulado rodando <command>munin-run <replaceable>extensão</replaceable></command> como root. Um segundo parâmetro potencial dado a esse comando (tal como <literal>config</literal>) é passado para a extensão como um parâmetro.

en: When a plugin is invoked with the <literal>config</literal> parameter, it must describe itself by returning a set of fields:
pt-BR: Quando uma extensão é invocada com o parâmetro <literal>config</literal>, ela tem que descrever a si própria pelo retorno de um conjunto de campos:

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" />
pt-BR: Os vários campos disponíveis são descritos pela Referência das Extensões (“Plugin reference”) disponível como parte do Guia do Munin (“Munin guide”). <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>.
pt-BR: Quando invocada sem um parâmetro, a extensão apenas retorna os últimos valores medidos; por exemplo, executando <command>sudo munin-run load</command> poderia retornar <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.
pt-BR: Finalmente, quando uma extensão é invocada com parâmetro <literal>autoconf</literal>, ela deveria retornar “yes” (e um status de término 0) ou “no” (com um status de término 1) de acordo sobre se a extensão deve ser habilitada nesta máquina ("host").

en: Configuring the Grapher
pt-BR: Configurando a Máquina que faz o Gráfico ("Grapher")

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>.
pt-BR: O “grapher” é simplesmente o computador que agrega os dados e gera os gráficos correspondentes. O software necessário está no pacote <emphasis role="pkg">munin</emphasis>. A configuração padrão roda o <command>munin-cron</command> (uma vez a cada 5 minutos), que reúne dados de todas as máquinas ("hosts") listados em <filename>/etc/munin/munin.conf</filename> (apenas a máquina ("host") local é listada por padrão), salva os dados históricos em arquivos RRD (<emphasis>Round Robin Database</emphasis>, um arquivo com formato desenvolvido par armazenar dados que variam com o tempo) armazenados em <filename>/var/lib/munin/</filename> e gera uma página HTML com os gráficos em <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.
pt-BR: Portanto todas as máquinas monitoradas tem que estar listadas no arquivo de configuração <filename>/etc/munin/munin.conf</filename>. Cada máquina é listada como uma seção completa, com um nome correspondendo com a máquina e pelo menos uma entrada com <literal>endereço</literal> dando o endereço IP correspondente.

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.
pt-BR: Seções podem ser mais complexas, e descrever gráficos extras que poderiam ser criados pela combinação de dados vindos de várias máquinas. Os exemplos fornecidos no arquivo de configuração são um bom ponto de partida para customizações.

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.
pt-BR: O último passo é publicar as páginas geradas; isso envolve a configuração de um servidor web para que o conteúdo de <filename>/var/cache/munin/www/</filename> seja disponibilizado em um site web. O acesso a esse site web geralmente será restrito, pelo uso de um mecanismo de autenticação ou controle de acesso baseado em IP. Veja <xref linkend="sect.http-web-server" /> para os detalhes relevantes.

en: Setting Up Nagios
pt-BR: Configurando o 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.
pt-BR: Diferentemente do Munin, o Nagios não necessariamente requer a instalação de alguma coisa nas máquinas (""hosts") monitoradas; na maioria das vezes, o Nagios é usado para conferir a disponibilidade de serviços de rede. Por exemplo, o Nagios pode se conectar em um servidor web e conferir que determinada página web pode ser obtida dentro de um determinado tempo.

en: Installing
pt-BR: Instalando

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:
pt-BR: O primeiro passo para configurar o Nagios é instalar os pacotes <emphasis role="pkg">nagios4</emphasis> e <emphasis role="pkg">monitoring-plugins</emphasis>. Ao instalar os pacotes, se configura a interface web e o servidor Apache. Os módulos Apache <literal>authz_groupfile</literal> e <literal>auth_digest</literal> devem estar habilitados Para isto execute:

en: Adding other users is a simple matter of inserting them in the <filename>/etc/nagios4/hdigest.users</filename> file.
pt-BR: Adicionar outro usuário é uma simples questão de inseri-los is no arquivo <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.
pt-BR: Apontar o navegador para <literal>http://<replaceable>servidor</replaceable>/nagios4/</literal> exibe a interface web; em particular, note que o Nagios já monitora alguns parâmetros da máquina aonde ele roda. Contudo, algumas funcionalidades interativas, tais como adicionar comentários a uma máquina ("host") não funciona. Esses recursos estão desabilitados pela configuração padrão do Nagios, que é muito restritiva por razões de segurança.

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:
pt-BR: Habilitar alguns recursos envolve editar <filename>/etc/nagios4/nagios.cfg</filename>. Nós também precisamos configurar permissões de escrita para o diretório usado pelo Nagios, através de comandos como os seguintes:

en: Configuring
pt-BR: Configurando

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>.
pt-BR: A interface web do Nagios é bem legal, mas elas não permite configurações, nem pode ser usada para adicionar máquinas ("hosts") monitorados e serviços. Toda a configuração é gerenciada através de arquivos referenciados pelo arquivo de configuração central, <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:
pt-BR: Não se deve mergulhar nesses arquivos sem algum entendimento dos conceitos do Nagios. A configuração lista objetos dos seguintes tipos:

en: a <emphasis>host</emphasis> is a machine to be monitored;
pt-BR: um <emphasis>host</emphasis> é a máquina a ser monitorada;

en: a <emphasis>hostgroup</emphasis> is a set of hosts that should be grouped together for display, or to factor some common configuration elements;
pt-BR: um <emphasis>hostgroup</emphasis> é um conjunto de máquinas que devem ser agrupadas para exibição, ou para fatorar alguns elementos comuns de configuração;

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);
pt-BR: Um <emphasis>service</emphasis> é um elemento testável relacionado a uma máquina ou um grupo de máquinas. Ele irá, muito frequentemente, ser uma checagem para um serviço de rede, mas ele também envolve a checagem de que alguns parâmetros estão dentro de um intervalo aceitável (por exemplo, espaço livre em disco ou carga do processador);

en: a <emphasis>servicegroup</emphasis> is a set of services that should be grouped together for display;
pt-BR: um <emphasis>servicegroup</emphasis> é um conjunto de serviços que devem ser agrupados para exibição;

en: a <emphasis>contact</emphasis> is a person who can receive alerts;
pt-BR: um <emphasis>contact</emphasis> é uma pessoa que pode receber alertas;

en: a <emphasis>contactgroup</emphasis> is a set of such contacts;
pt-BR: um <emphasis>contactgroup</emphasis> é um grupo de tais pessoas;

en: a <emphasis>timeperiod</emphasis> is a range of time during which some services have to be checked;
pt-BR: um <emphasis>timeperiod</emphasis> é um intervalo de tempo durante o qual alguns serviços tem que ser checados;

en: a <emphasis>command</emphasis> is the command line invoked to check a given service.
pt-BR: um <emphasis>command</emphasis> é a linha de comando invocada para checar um dado serviço.

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.
pt-BR: De acordo com seu tipo, cada objeto tem um número de propriedades que podem ser customizadas. Um lista completa seria muito longa para ser incluída, mas as propriedades mais importantes são as relações entre os objetos.

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.
pt-BR: Um <emphasis>service</emphasis> (serviço) usa um <emphasis>command</emphasis> (commando) para checar o estado de uma funcionalidade em um <emphasis>host</emphasis> (máquina) (ou um <emphasis>hostgroup</emphasis>) dentro de um <emphasis>timeperiod</emphasis> (intervalo de tempo). Em caso de um problema, o Nagios envia um alerta para todos os membros de <emphasis>contactgroup</emphasis> (grupo de contatos) ligados ao serviço. É enviado um alerta a cada membro de acordo com o canal descrito no objeto <emphasis>contact</emphasis> (contato) correspondente.

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.
pt-BR: Um sistema de herança permite o fácil compartilhamento de um conjunto de propriedades entre muitos objetos sem a duplicação de informação. Além disso, a configuração inicial inclui um número de objetos padrão; em muitos casos, a definição de novas máquinas, serviços e contatos é uma simples questão de derivação a partir dos objetos genéricos fornecidos. Os arquivos em <filename>/etc/nagios4/conf.d/</filename> são uma boa fonte de informação sobre como eles funcionam.

en: The Falcot Corp administrators use the following configuration:
pt-BR: Os administradores da Falcot Corp usam a seguinte configuração:

en: <filename>/etc/nagios4/conf.d/falcot.cfg</filename> file
pt-BR: Arquivo <filename>/etc/nagios4/conf.d/falcot.cfg</filename>

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>.
pt-BR: Este arquivo de configuração descreve duas máquinas monitoradas. A primeira é o servidor web, e a checagem é feita nas portas HTTP (80) e HTTP-seguro (443). O Nagios também checa o funcionamento de um servidor SMTP na porta 25. A segunda máquina é um servidor FTP, e a checagem inclui garantir que uma resposta venha em 20 segundos. Além desse intervalo, um <emphasis>warning</emphasis> é emitido; além de 30 segundos, o alerta é considerado crítico. A interface web do Nagios também mostra que um serviço SSH é monitorado: isso vem de máquinas pertencentes ao grupo de máquinas <literal>ssh-servers</literal>. O serviço padrão correspondente é definido em <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.
pt-BR: Note o uso da herança: um objeto é feito para herdar de outro objeto através de “use <replaceable>parent-name</replaceable>”. O objeto pai tem que ser identificável, o que requer dar a ele uma propriedade “name <replaceable>identifier</replaceable>”. Se o objeto pai não se destina a ser um objeto real, mas apenas servir como um pai, dar-lhe uma propriedade “register 0” informa ao Nagios para não considerá-lo, e assim ignorar a falta de alguns parâmetros que de outra forma seriam necessários.

en: <emphasis>DOCUMENTATION</emphasis> List of object properties
pt-BR: <emphasis>DOCUMENTAÇÃO</emphasis> Lista de propriedades do objeto

en: <emphasis>GOING FURTHER</emphasis> Remote tests with NRPE
pt-BR: <emphasis>INDO ALÉM</emphasis> Testes remotos com NRPE
