faculdade de tecnologia senai de desenvolvimento gerencial...

FACULDADE DE TECNOLOGIA SENAI DE DESENVOLVIMENTO GERENCIAL - FATESG

CURSO SUPERIOR EM TECNOLOGIA EM REDE DE COMPUTADORES

Diogo Ezídio da Silva Gilberto Lima de Oliveira

Leandro de Sousa Rangel Lucas Timm Florão

VIRTUALIZAÇÃO COMO ALTERNATIVA PARA AMBIENTE DE SERVIDORES

Goiânia 2008

Diogo Ezídio da Silva Gilberto Lima de Oliveira


VIRTUALIZAÇÃO COMO ALTERNATIVA PARA AMBIENTE DE SERVIDORES

Trabalho de Conclusão de Curso – TCC apresentado á Faculdade de Tecnologia SENAI DE Desenvolvimento Gerencial – FATESG, para a obtenção do título de Graduado em Tecnologia em Redes de Computadores. Orientador: Prof. Msc. Mauricio Severich

Goiânia 2008

CURSO SUPERIOR EM TECNOLOGIA EM REDE DE COMPUTADORES

Diogo Ezídio da Silva Gilberto Lima de Olivera


Virtualização como alternativa para ambiente de ser vidores

Trabalho de Conclusão de Curso – TCC apresentado á Faculdade de Tecnologia SENAI DE Desenvolvimento Gerencial – FATESG, para a obtenção do título de Graduado em Tecnologia em Redes de Computadores.

Aprovada em _______ de _____________________________ de 2008

Banca Examinadora

Professor Msc. Maurício Severich

Professor Msc. Rafael Leal Martins

Professora Msc. Ana Flávia Marinho de Lima Garrati

Dedicamos este trabalho de conclusão de curso a todos os nossos familiares que nos apoiaram, à FATESG por ter acreditado no Curso Superior em Tecnologia em Rede de Computadores e ao orientador, Professor que, com dedicação e conhecimento, orientou-nos no decorrer deste trabalho.

Agradecemos, primeiramente a DEUS, que nos deu saúde e disposição nestes anos, aos colegas que contribuíram e incentivaram para realização desse trabalho e também aos professores que com sabedoria nos acompanharam nesses anos em que decorreu o curso e, em especial ao nosso orientador que nos acompanhou em todas as etapas desse trabalho. Também aos amigos e a família pela compreensão de nossa ausência para a elaboração do mesmo.

“Uma mente que se abre a uma nova idéia jamais volta ao seu tamanho original”.

(Albert Einstein)

RESUMO

Este trabalho apresenta uma visão geral da virtualização para uso em servidores. A virtualização perante a tecnologia da informação consiste em utilizar um único host físico para a criação de dois ou mais sistemas operacionais que funcionam simultaneamente. Neste documento, a virtualização foi utilizada para criação de um ambiente computacional de servidores comparando três softwares utilizados para tal finalidade: O Xen, Vmware Server e Linux KVM. Testes foram realizados visando obter resultados práticos da virtualização de servidores como forma de diminuir custos em TI através do melhor aproveitamento de hardware, bem como o detalhamento de informações sobre esta tecnologia que se torna a cada dia mais presente no cenário de TI das grandes empresas.

PALAVRAS-CHAVE: Virtualização, Xen, VMware, Linux

ABSTRACT

This paper shows a general visualization of virtualization for servers’ use. The virtualization at the Information Technology scene is consisted in the use from a single physichal host to install and creation of two or more operational systems that runs simultaneously. In this document, the virtualization was used to simulate a server data-center comparing three softwares commonly used to this end: Xen, VMware Server and Linux KVM. Tests was ran to take practical results of server virtualization, as a way to reduce IT coasts and to get a better hardware utilization, also the technical information about this technology, which everyday becomes more and more present on the IT scene of big employments. KEY-WORDS: Virtualization, Xen, Vmware, Linux

LISTA DE ILUSTRAÇÕES

Figura 1: Emulação de Hardware..............................................................................22 Figura 2: Virtualização Completa ..............................................................................23 Figura 3: Hypervisor ..................................................................................................24 Figura 4: Instruction Set Virtualization.......................................................................25 Figura 5: Linux KVM..................................................................................................31

LISTA DE GRÁFICOS

Gráfico 1 - Comparativo de Processos......................................................................41 Gráfico 2 - Operações com Inteiros...........................................................................42 Gráfico 3 - Operações com Floats.............................................................................43 Gráfico 4 - Operações com Doubles .........................................................................44 Gráfico 5 - Context Switching....................................................................................45 Gráfico 6 - Latência de Comunicação Local..............................................................46 Gráfico 7 - Latência de Sistema de Arquivos ............................................................47 Gráfico 8 - Largura de Banda para Comunicação Local ...........................................48 Gráfico 9 - Comparativo de Latência de memória .....................................................49 Gráfico 10 - Média de Latência de Memória..............................................................50 Gráfico 11 - Transferência de Arquivos em NFS.......................................................52 Gráfico 12 - Codificação de vídeo .............................................................................53 Gráfico 13 - Connection Times para 100 requisições por rajada...............................55 Gráfico 14 - Porcentagem de Requisições por Tempo..............................................56 Gráfico 15 - Connection Times para 200 requisições por rajada...............................58 Gráfico 16 - Porcentagem de Requisições por Tempo..............................................59

LISTA DE ABREVIATURAS SIGLAS E SÍMBOLOS

AMD - Advanced Micro Devices

ARM – Advanced Risc Machine

BARE METAL – Software instalado diretamente em hardware

BSD – Berkeley Software Distribution

CPU – Central Processing Unit

CTSS - Compatible Time-Share System

DMA – Direct Memmory Access

DOUBLE – Número de tamanho duplo

FLOAT – Número fracionado (com ponto flutuante)

HCL - Hardware Compatible List - Lista de Hardware Compatível

I/O – Input/Output

IDC – International Data Corporation

INTEGER – Número inteiro

Intel VT – Intel Virtualization Technology

KVM – Kernel-based Virtual Machine

MIPS – Microprocessor without interlocked pipeline stages

MIT – Massachusetts institute of Technology

MRTG – Multi-Router Traffic Grapher

NFS – Network File System

PAE – Phisical Addressing Extentions

POWER – Power Optimization Enhanced Risc

PowerPC - Power Optimization With Enhanced RISC - Performance Computing

Pseudo-Hardware – Hardware visualizado pela máquina virtual.

QEMU-DM – QEMU Device-Manager

SCSI - Small Computer Systems Interface - Interface para Sistemas de Pequenos

Computadores

SMB – Service Message Blocks

SMP - Symmetric multiprocessing - Multi Processamento Simétrico.

SNMP – Simpe Network Manage Ment Protocol

SPARC – Scalable Processor Architecture

USB - Universal Serial Bus

VMM – Virtual Machine Monitor

Vmotion – Migração viva

VT - Intel Virtualization Technology – Tecnologia de Virtualização Intel

SUMÁRIO

SUMÁRIO .................................................................................................................12

1 INTRODUÇÃO......................................................................................................15

1.1 OBJETIVO..........................................................................................................16

2 METODOLOGIA........................................ ...........................................................17

2.1 DETALHAMENTO TEÓRICO.............................................................................17

2.2 AMBIENTE DE TESTES REALIZADOS.............................................................17

3 VIRTUALIZAÇÃO...................................... ...........................................................18

3.1 A ORIGEM DA VIRTUALIZAÇÃO ......................................................................18

3.1.1 Visão Histórica da Virtualização ................... ...............................................18

3.1.2 A Virtualização na Plataforma X86...............................................................19

3.2 A IMPORTÂNCIA DA VIRTUALIZAÇÃO............................................................20

3.3 TIPOS DE VIRTUALIZAÇÃO .............................................................................21

3.3.1 A Emulação de Hardware ............................. ................................................21

3.3.2 A Virtualização Completa ........................... ..................................................22

3.3.3 A Paravirtualização ................................ .......................................................24

3.3.4 Instruction Set Virtualization – Virtualização de Instruções ..................... 25

4 IMPLEMENTAÇÕES PARA VIRTUALIZAÇÃO.................. .................................27

4.1 QEMU.................................................................................................................27

4.2 XEN ....................................................................................................................28

4.2.1 Sistemas Operacionais Suportados................... .........................................29

4.2.2 Hardware requerido ................................. .....................................................30

4.3 LINUX KVM ........................................................................................................30

4.3.1 Componentes do KVM................................. .................................................32

4.3.2 Gerenciamento ...................................... ........................................................32

4.4 VMWARE SERVER............................................................................................33

4.4.1 Novos recursos no VMware Server 2 ..........................................................33

4.5 VMWARE ESX SERVER....................................................................................34

4.5.1 VMware ESXi ........................................ .........................................................35

4.6 VMWARE WORKSTATION................................................................................35

4.7 SUN XVM, ..........................................................................................................35

4.7.1 Suporte a guests ................................... ........................................................36

4.8 QUADRO COMPARATIVO DAS FERRAMENTAS ............................................36

5 EXPERIMENTOS E RESULTADOS.......................... ...........................................38

5.1.1 Descrição do Ambiente .............................. ..................................................38

5.1.2 Análise de Desempenho.............................. .................................................38

5.2 LMBENCH..........................................................................................................39

5.2.1 Manipulação de Processos ........................... ...............................................40

5.2.2 Operações com Números Inteiros ..................... ..........................................41

5.2.3 Operações com Números fracionários ( Floats) .........................................42

5.2.4 Operações com Números Dobrados ( Double)............................................44

5.2.5 Context Switching – Troca de Contexto............................... .......................45

5.2.6 Latência para Comunicação Local .................... ..........................................46

5.2.7 Latência de sistema de arquivos .................... .............................................46

5.2.8 Largura de banda para comunicação local............ .....................................47

5.2.9 Latência de Memória................................ .....................................................48

5.2.10 Média de Latência de Memória ....................... .............................................49

5.3 TRANSFERÊNCIA DE ARQUIVOS ...................................................................50

5.3.1 SMB ................................................................................................................51

5.3.2 NFS .................................................................................................................51

5.4 CODIFICAÇÃO DE VÍDEO.................................................................................52

5.5 BENCHMARK DE SERVIDOR WEB..................................................................53

5.5.1 100 requisições por rajada ......................... ..................................................54

5.5.2 200 requisições por rajada ......................... ..................................................57

6 CONSIDERAÇÕES FINAIS............................... ...................................................60

6.1 DIFICULDADES ENCONTRADAS.....................................................................61

6.2 LIMITAÇÕES......................................................................................................62

6.3 EXPERIMENTOS FUTUROS.............................................................................62

6.4 CONCLUSÕES ..................................................................................................63

REFERÊNCIAS BIBLIOGRÁFICAS......................... ................................................64

ANEXO A: ARQUIVO DE CONFIGURAÇÃO PARA INSTALAÇÃO CO M XEN .....66

ANEXO B: ARQUIVO DE CONFIGURAÇÃO APÓS A INSTALAÇÃO COM XEN..67

ANEXO C: CRIAÇÃO DE MÁQUINA VIRTUAL COM KVM ........ ............................68

ANEXO D: REDE BRIDGE DO QEMU-KVM................... .........................................69

ANEXO E: SAÍDA DE EXECUÇÃO DO LBENCH NO KVM ........ ............................70

ANEXO F: SAÍDA DE EXECUÇÃO DO LBENCH NO XEN........ .............................72

ANEXO G: SAÍDA DE EXECUÇÃO DO LBENCH NO VMWARE SERV ER............74

ANEXO H: SAÍDA DE EXECUÇÃO DA CODIFICAÇÃO DE VIDEO NO KVM........76

ANEXO I: SAÍDA DE EXECUÇÃO DA CODIFICAÇÃO DE VIDEO NO XEN..........77

ANEXO J: SAÍDA DE EXECUÇÃO DA CODIFICAÇÃO DE VIDEO NO VMWARE 78

ANEXO K: SAÍDA DE EXECUÇÃO DO AB NO KVM............ ..................................79

ANEXO L: SAÍDA DE EXECUÇÃO DO AB NO XEN............ ...................................81

ANEXO M: SAÍDA DE EXECUÇÃO DO AB NO VMWARE SERVER .. ...................83

ANEXO N: SAÍDA DE EXECUÇÃO DAS CÓPIAS DE ARQUIVO PO R NFS..........85

15

1 INTRODUÇÃO

Através de uma definição livre, virtualização é o processo de executar

vários sistemas operacionais em um único equipamento. Uma máquina virtual é um

ambiente operacional completo que se comporta como se fosse um computador

independente. Com a virtualização, um servidor pode manter vários sistemas

operacionais em uso.

Segundo GOLDEN & SCHEFFY (2008), a criação de um ambiente data

center demanda recursos, que devem ser bem direcionados. A cada servidor

adquirido é necessária a adequação do espaço físico, verificação do circuito elétrico

de alimentação e recabeamento nos ativos de rede, assim como a avaliação do

custo do equipamento com gasto de energia e manutenção por toda a sua vida útil.

Porém, uma vez estabelecido um ambiente de servidores, as circunstâncias podem

levar a necessidade de ampliação do mesmo, o que pode gerar transtornos caso

não sejam analisados os itens acima.

Através da virtualização, esta ampliação pode ser obtida sem a

necessidade real da aquisição de novo equipamento em hardware. Como

conseqüência, haveria a possibilidade de colocar vários servidores virtuais em

operação na mesma máquina física, usando os recursos de hardware de forma

otimizada e equilibrada. Assim, pode-se economizar gastos com energia,

refrigeração e espaço físico.

Atualmente, muitos data centers possuem servidores que utilizam apenas 10 ou 15% da capacidade total de processamento. Em outras palavras, 85 ou mais de 90% de toda a capacidade de cada servidor está em desuso. Entretanto, ainda que um servidor esteja com baixa utilização de recursos, ele continua ocupando espaço físico e desperdiçando energia elétrica, gerando os mesmos custos operacionais que os de uma máquina com 100% de utilização em tempo total. (GOLDEN & SCHEFFY, 2008, p. 3)

A primeira e mais óbvia vantagem da virtualização é a redução de custos. Com apenas uma máquina que possua os recursos suficientes é possível montar uma estrutura com vários servidores virtuais, dispensando a aquisição de várias máquinas. Operacionalmente também há vantagens, pois a administração se torna centralizada e o tempo total de manutenção é inevitavelmente reduzido. (SIQUEIRA, 2007, p. 4)

16

O pensamento de GOLDEN & SCHEFFY (2008) assinala também estar de

acordo com a proposição de SIQUEIRA (2007), quando cita que além de uma

grande conquista na redução de custos em data centers, a virtualização oferece a

oportunidade de reduzir largamente o custo com a administração dos sistemas, pois

reduzirá a quantidade de equipamentos físicos que necessitam de administração.

Várias tarefas associadas a administração dos servidores (como a instalação de

sistemas operacionais, aplicação de patches e a realização de backups) continuarão

existindo em ambientes virtualizados, mas poderão desaparecer nos servidores

físicos.

A virtualização proporciona novos recursos não convencionais, como a

migração em tempo real, que permite que um sistema virtualizado mude seu host

hospedeiro sem comprometer a produção, recurso imprescindível para ambientes

críticos com requerimento de alta disponibilidade.

1.1 OBJETIVO

A realização deste trabalho tem como objetivo principal explorar a

virtualização de servidores como forma de obter melhor aproveitamento de

hardware, comparando três softwares para tal finalidade: VMware Server, Xen

Hypervisor e Linux KVM.

17

2 METODOLOGIA

A construção do trabalho ocorreu através do levantamento bibliográfico a

respeito da origem, histórico e tipos existentes de virtualização, e de vários

softwares utilizados com essa finalidade.

Destes softwares, foram escolhidos três para experimentação e avaliação

de desempenho. Eles foram testados individualmente em cada modalidade.

Assim, a construção do trabalho foi feita em duas etapas principais,

descritas abaixo:

2.1 DETALHAMENTO TEÓRICO

Foram identificados conceitos teóricos sobre o assunto, bem como o

histórico da virtualização desde sua primeira utilização. Promoveu-se os

levantamentos de informações técnicas sobre alguns tipos de virtualização, alguns

softwares utilizados atualmente para virtualizar e o comparativo de suas vantagens e

desvantagens.

2.2 AMBIENTE DE TESTES REALIZADOS

Os experimentos foram realizados em um ambiente de produção, para o

qual foram criadas máquinas virtuais utilizando os softwares VMware Server, Xen

Hypervisor e Linux KVM, nas quais serão executados testes com diferentes tipos de

cargas simulando o uso prático das mesmas. Mais detalhes sobre o ambiente,

consulte o item 5.1.1 Descrição do Ambiente.

18

3 VIRTUALIZAÇÃO

3.1 A ORIGEM DA VIRTUALIZAÇÃO

O grande foco da virtualização, atualmente, é a chamada “virtualização de

servidores”, ou a hospedagem de múltiplos e independentes sistemas operacionais

em um único computador físico. Esta seção discorre sobre as raízes deste

procedimento.

3.1.1 Visão Histórica da Virtualização

O conceito de virtualização é antigo: Data os anos 60, com o uso mais

precoce realizado no antigo IBM 7044 CTSS (Compatible Time-Share System –

Sistema Compatível com Compartilhamento de Tempo); Segundo JONES (2006)

este equipamento foi denominado "Projeto Atlas", oriundo de um estudo realizado

em conjunto com o MIT (Massachusetts Institute of Technology – Instituto de

Tecnologia do Massachusetts), a Ferranti Ltd. e a University of Manchester

(universidade de Manchester), no qual foi utilizado um mainframe IBM 704 M44/44X

com implementação de chamadas supervisoras.

O sistema operacional deste mainframe (na época chamado "Supervisor")

executava duas máquinas virtuais, uma para o sistema e uma para execução de

programas, servindo de base para outros computadores que viriam após ele.

Assim, com base nesta tecnologia, em 1966 foi lançado o mainframe IBM

System/360 modelo 67, onde o hardware do equipamento era inteiramente

acessado através de uma interface chamada VMM (Virtual Machine Monitor). O

VMM funcionava diretamente no hardware básico do equipamento, permitindo então

a execução de máquinas virtuais. Cada máquina virtual poderia ser uma nova

instância do mesmo sistema operacional base em prévia execução.

19

Com essa funcionalidade, o antigo termo "Supervisor" foi então

denominado "Hypervisor". Ou seja, um software que provê ambiente de virtualização

para o sistema operacional rodando acima dele.

No início da década de 70, a IBM anunciou a série de mainframes

System/370, e em 1972 anunciou o sistema operacional VM/370, que permitia a

criação de múltiplas máquinas virtuais para os mainframes desta série. O VM/370 foi

atualizado em conjunto com toda a linha de mainframes da IBM, e hoje é conhecido

como IBM z/VM, um dos sistemas operacionais para os mainframes da série

System/Z, e mantém compatibilidade total com os aplicativos desenvolvidos ainda

para o System/370.

3.1.2 A Virtualização na Plataforma X86

Segundo a VMware Inc. (2008), a virtualização perdeu forças nas décadas de

80/90 devido a criação de novas aplicações cliente/servidor e do declínio da

plataforma mainframe. Devido ao alto custo inicial de um mainframe, empresas

passaram a adquirir servidores de plataforma x86 de acordo com a demanda que

precisavam.

A larga ascensão da plataforma Linux nos servidores, assim como a adoção do sistema operacional Windows em desktops e posteriormente em alguns servidores nos anos 90, acabaram por consolidar a plataforma x86 como alternativa viável para uso na virtualização. (VMware Inc. 2008)1

Os mainframes tinham grande capacidade de processamento, o que não

existia no início da ascensão da plataforma x86. Os servidores x86 também não

eram projetados com foco em virtualização, como os mainframes foram nas décadas

passadas (e são até os dias atuais). Assim, de acordo com a IDC (International Data

Corporation, [1999?] apud VMware Inc, 2008) em cada implementação de algum

servidor x86 típico, o teto de uso das CPUs acaba entre 10 a 15% da capacidade

total deste servidor. Isso acontecia porque, para cada servidor x86, geralmente

1 Conteúdo disponível no endereço http://www.vmware.com/overview/history.html

20

utilizava-se uma única determinada aplicação, visando garantir boa margem de risco

contra problemas que possam comprometer a produção.

Segundo GOLDEN & SCHEFFY (2008), a virtualização quebra o molde

“uma aplicação, um servidor”, pois veio para suportar várias aplicações em um só

sistema físico. Então, em 1999, a VMware Inc. introduziu a virtualização na

plataforma x86 como uma maneira mais eficiente para utilizar o equipamento desta

plataforma, aproveitando servidores x86 de propósito geral para prover uma

estrutura compartilhada de hardware oferecendo isolamento completo, mobilidade e

liberdade de escolha para sistemas operacionais em ambientes de servidores.

3.2 A IMPORTÂNCIA DA VIRTUALIZAÇÃO

De uma perspectiva empresarial, existem muitas razões para utilizar a

virtualização, principalmente na chamada “Consolidação de Servidores”. Ao

virtualizar determinado número de sistemas sub-utilizados em um único servidor

físico, você economizará espaço em estrutura física, espaço em disco, refrigeração,

energia e centralizará o gerenciamento.

Para determinar quais servidores podem ou não ser virtualizados, deve-se

fazer uma avaliação de recursos utilizando-se de ferramentas como MRTG2 ou

Cacti3 (ambos utilizam SNMP4) para monitorar a performance e o uso de recursos

em cada servidor. Uma vez virtualizado, deve ser feito um acompanhamento,

verificando se o novo servidor físico também ficará sobrecarregado, é possível

migrar determinado servidor virtual para outro servidor físico com o mesmo em

produção – sem necessidade de reboot. Assim, pode ser feito o balanceamento de

carga entre vários servidores físicos hospedeiros sem afetar o funcionamento das

máquinas virtuais.

2 MRTG: Multi-Router Traffic Grapher. Software utilizado para gerar gráficos de determinados equipamentos. 3 CACTI: Software utilizado para geração de gráfico e monitoramento de equipametnos. 4 SNMP: Simple Network Management Protocol, Protocolo Simples para Gerenciamento de Redes. Protocolo utilizado para obter informações de dispositivos que o suportem para utilização por outras aplicações.

21

A virtualização também é importante ao analisarmos a redundância em

data centers, item importantíssimo em ambientes 24 x 7 (24 horas por dia, sete dias

da semana). Com a migração em tempo real, uma vez identificada a possibilidade

de falha de determinada máquina física hospedeira (quebra de espelhamento, fonte

queimando, memória despejando etc), bastaria migrar as máquinas virtuais para

outros servidores físicos. Porém, se acontecer alguma falha não esperada em algum

servidor hospedeiro, todas as máquinas virtuais daquele equipamento podem ser

afetadas. Exemplo, se todas as fontes de um servidor queimarem ao mesmo tempo,

todas as máquinas virtuais dele desligarão. Ou, se acontecer alguma falha nos

discos do servidor – ou na storage de armazenamento -, todas máquinas virtuais

poderão ser corrompidas.

3.3 TIPOS DE VIRTUALIZAÇÃO

A virtualização é um conceito amplo e existem vários usos e categorias

para efetuá-la. As principais maneiras serão abordadas nesta seção.

3.3.1 A Emulação de Hardware

Segundo JONES (2006), a emulação de hardware é atualmente a forma

mais complexa de virtualização. Devido a sua complexidade, gera grandes

overheads5, prejudicando o desempenho do sistema operacional guest6. Nesse

método, todo o hardware de uma máquina virtual é criado via software no sistema

hospedeiro para emular o hardware proposto, conforme exibido na Figura 1. Ou

seja, até o processador da máquina virtual precisa ser criado via software, o que é

feito geralmente feito em assembly.

5 Overhead: Diferença de performance gerando latência no sistema operacional guest 6 Guest: Sistema operacional convidado.

22

Figura 1: Emulação de Hardware

Segundo GOLDEN & SCHEFFY (2008), a complexidade da técnica fere o

desempenho do guest. E, segundo JONES (2006), para emulações de alta-

fidelidade, incluindo transições de informação entre registradores para memória

cache e criação de pipelines na CPU, a performance pode ser, facilmente, 1000

vezes menor.

Mas, a emulação de hardware também tem vantagens, Por exemplo,

usando emulação de hardware, é possível rodar um sistema operacional guest sem

qualquer modificação ou adaptação.

3.3.2 A Virtualização Completa

A virtualização completa, também conhecida como "virtualização nativa", é

outro método utilizado para virtualização. JONES (2006) cita que esse modelo usa

uma máquina virtual através da mediação entre o sistema operacional hospedeiro

(host) e o guest conforme mostrado na Figura 2. A palavra "mediação" é utilizada,

pois o VMM faz a troca entre o sistema operacional virtualizado e o hardware do

equipamento.

23

Figura 2: Virtualização Completa

Segundo JONES (2006), a virtualização completa é mais rápida que a

emulação de hardware, mas a performance também é menor do que a do mesmo

sistema operacional rodando nativamente. A grande vantagem da virtualização

completa é que o sistema operacional pode rodar sem modificações. A desvantagem

é que a máquina guest não pode rodar em host de arquitetura diferente.

Segundo à VMware Inc. (2008), um grande obstáculo para a virtualização

completa foi o fato de que, 17 instruções específicas dos processadores da

plataforma x86 geravam erros quando essa camada de interpretação era criada, o

que fazia o sistema operacional guest gerar erros críticos durante sua execução.

Esses erros variavam desde informações no sistema operacional até a finalização

inesperada da aplicação.

Assim, essas 17 instruções foram apontados pela mesma empresa como

um importante marco para a criação do primeiro ambiente de virtualização completa

da plataforma x86, o VMware Workstation em sua primeira versão, lançado em

1999.

24

3.3.3 A Paravirtualização

A paravirtualização é uma técnica que tem poucas semelhanças com a

virtualização completa. Esse método usa o hypervisor para acesso compartilhado ao

hardware do equipamento, e também integra códigos de virtualização dentro do

sistema operacional nativo, agregando nele as funções de gerenciamento do

hypervisor, como exibido na Figura 3.

GOLDEN & SCHEFFY (2008) cita que através da paravirtualização, o

hypervisor é criado como uma camada abaixo do sistema operacional, que por sua

vez, multiplexa o acesso dos guests ao hardware do equipamento. Assim, o próprio

sistema operacional nativo (e, neste caso, de gerenciamento) é transformado em

máquina virtual.

Figura 3: Hypervisor

Segundo SIQUEIRA (2007), este modelo como hypervisor obtém

preferência para os ambientes virtualizados, pois, os hóspedes sabem perfeitamente

25

que rodam em um ambiente virtual. Para isso, os guests precisam ser corrigidos, o

que só é possível de conseguir em sistemas de código aberto7.

Uma vez que os sistemas operacionais sejam adaptados, a interação

entre as máquinas virtuais e a máquina física é otimizada, o que aumenta o

desempenho. Porém, a grande desvantagem deste modelo continua sendo a

dependência da alteração do sistema operacional de gerenciamento e dos guests,

para que possam interagir com o hypervisor ao invés do hardware físico.

3.3.4 Instruction Set Virtualization – Virtualização de Instruções

Outro aspecto mais recente da virtualização é chamado Instruction Set

Virtualization (Virtualização de Instruções). Neste modelo, segundo JONES (2006),

um conjunto de instruções virtuais é traduzido para uma instrução física destinada à

camada de hardware do equipamento. Assim, com o código original sendo

executado dentro de uma máquina virtual, a tradução ocorre do primeiro (set de

instruções) para um segundo seguimento de código, efetuando a mediação entre a

aplicação e o sistema operacional conforme exibido na Figura 4.

Figura 4: Instruction Set Virtualization

Um exemplo recente deste modelo é utilizado no processador Crusoe, da

Transmeta. A arquitetura implementa tradução de binários com o nome Code

7 Código Aberto: Programas que possuem o código de fonte disponível para verificação e/ou estudo.

26

Morphing. O mesmo processo também é utilizado para execução de binários de

diferentes arquiteturas em um sistema operacional de outra plataforma, como por

exemplo, para rodar binários de um sistema Linux plataforma PowerPC em um Linux

plataforma x86 com o software “nspluginwrapper”.

27

4 IMPLEMENTAÇÕES PARA VIRTUALIZAÇÃO

Foram analisados os aspectos relevantes de vários softwares utilizados

para virtualização.

Os softwares descritos a seguir, foram escolhidos por serem largamente

utilizados na virtualização para desktop (com usuários que desejam testar outros

sistemas operacionais e simularem ambientes) e também para virtualização de

servidores. Eles pertencem a distintas categorias, conforme está descrito a seguir:

4.1 QEMU

O QEmu é dos virtualizadores mais complexos hoje existentes, mas que

suporta várias maneiras de execução. Por padrão, é um emulador de hardware (e

sofre com a baixa performance), mas também suporta emulação de processadores

de outras arquiteturas, como ARM, MIPS, Sparc e PowerPC. Em modo de emulação

de um computador x86, o QEMU disponibiliza os seguintes componentes de

hardware:

- Chipset Intel i440FX/PIIX3

- Placa de vídeo Cirrus 446 PCI

- Teclado e mouse PS/2

- 2 PCI IDEs com suporte a CD-Rom

- Disquete 3 ½ polegadas

- Porta serial

- Placa de som Creative SoundBlaster 16, ENSONIQ AudioPCI ES1370

Yamaha YM3812.

- Suporte a USB.

Ele também pode ser apenas um emulador de binários, e nesse modelo é

chamado “User Mode Emulation”. Dessa forma, ele pode permitir que um binário

28

compilado para Linux em plataforma x86 rode em plataforma PowerPC, por

exemplo. Outras funcionalidades são agregadas a ele com o módulo KQEMU, que

garante maior aceleração ao host em execução quando este é um x86.

4.2 XEN

O Xen é um hypervisor que trabalha tanto em modo de paravirtualização

como em modo de virtualização completa. Está localizado abaixo do sistema

operacional. Ele permite que os recursos de hardware de uma máquina sejam

dinamicamente distribuídos entre as máquinas virtuais. E nele, as máquinas virtuais

são denominadas Domains.8 O próprio sistema operacional nativo (que é utilizado

para gerenciamento) é referenciado como um Domain.

Ao contrário do VMware Workstation/Server, em modo de

paravirtualização, ele não tenta virtualizar completamente as chamadas do sistema

operacional guest para a camada de hardware. Assim, partes do sistema

operacional guest são modificadas para trabalharem em interação direta com ele, ao

invés do hardware nativo do equipamento, conforme descrito em Xen Interfaces’

Manual.

Por isso, o Xen em modo paravirtualizado não disponibiliza pseudo-

hardware9 para a máquina virtual. Nada é exibido nos comandos lspci e lsusb; No

comando dmesg, os dispositivos xenblk, xen_mem e xenfb apenas indicam que o

kernel foi preparado para integração direta com o hypervisor.

Quando utilizada a virtualização completa no Xen, o hardware encontrado

na máquina virtual é criado através da modificação do software QEMU, e o hardware

disponibilizado para o sistema operacional guest é o mesmo exibido por este, exceto

o processador.

8 Domains: Nomenclatura adotada no Xen para denominar suas máquinas virtuais. 9 Pseudo-Hardware: Hardware visualizado pela máquina virtual.

29

Em ambos os casos, o pseudo-hardware exportado para as máquinas

virtuais (CPU, memória, rede e dispositivos de bloco) é gerado através de uma

interface de controle utilizada para gerenciamento no Xen. Assim, para a abstração

de hardware das máquinas virtuais (nos dois modos), fica em constante execução o

daemon xend na máquina de gerenciamento.

O acesso a essa interface de controle é restrito: Ela pode ser acessada

por uma única máquina virtual privilegiada, conhecida como Domain 0 (Domínio 0).

As operações como a criação de um novo domínio, desligamento e até migração de

um domínio em execução para outro host físico, são disparadas diretamente pelo

Domain 0 (máquina de gerenciamento) para o hypervisor através do comando xm,

que executa a solicitação.

O Domain 0 é criado automaticamente quando o sistema executa o boot10.

Durante isso, o Xen agrega os privilégios de gerenciamento para este domínio, de

modo que ele possa interagir diretamente com o hypervisor executando, também, as

tais tarefas administrativas.

4.2.1 Sistemas Operacionais Suportados

Segundo o Manual do Usuário do Xen a paravirtualização permite uma

performance excelente durante o processo de virtualização, uma vez que a

arquitetura x86 só recebeu aperfeiçoamentos (instruções específicas) para tal uso a

partir de 2006. Então, para executar um domínio em modo de paravirtualização, é

necessário que o sistema operacional seja portado para o Xen. Atualmente, os

sistemas operacionais portados para o Xen são o Linux, NetBSD e o Solaris. Esses

sistemas podem ser executados no Xen em modo paravirtualizado.

Para utilizar virtualização completa no Xen, é necessário o suporte para

virtualização via hardware. Esse suporte é garantido pelas instruções VT nos

processadores Intel e SVM nos processadores da AMD. Existindo essas extensões,

10 Boot: Processo de inicialização do sistema.

30

é possível que o Xen crie Domains sem necessidade alguma de modificação do

sistema operacional, podendo assim ser instalado qualquer outro guest.

4.2.2 Hardware requerido

Atualmente, o Xen roda nos computadores da plataforma x86, sendo

necessário algum processador P6 (de sexta geração), como um Pentium Pro,

Celeron, Pentium II, Pentium III, Pentium IV, Xeon, AMD Athlon (Duron), Athlon 64 e

Opteron. Multi-processamento é suportado, e existem portes em andamento para as

plataformas Intel IA64 (processador Itanium) e Power (processadores PowerPC e

POWER).

O Xen, por padrão, suporta até de 4GB de memória RAM em modo de

execução 32 bits. Como é uma quantidade pequena para os servidores nos dias

atuais, existe o suporte para as extensões PAE11, da Intel, que permite que sistemas

operacionais x86 de 32bits possam endereçar até 64GB de memória Ram. O Xen

3.0 também suporta as arquiteturas x86/64 bits.

4.3 LINUX KVM

Segundo a Qumranet Inc, desenvolvedora do KVM, adicionando a

capacidade de virtualização no kernel Linux, é possível aproveitar todo o código já

escrito do para a criação de um ambiente de virtualização completo nativo. Integrado

ao kernel, o KVM automaticamente suporta todos os dispositivos de hardware que

funcionam com Linux.

Com o VMM integrado ao kernel, e não abaixo dele (exemplo do Xen),

cada máquina virtual é um processo normal no sistema operacional, acessada

11 PAE: Phisical Addressing Extensions. Extensões de Endereçamento Físico.

31

através do módulo KVM, módulo este que executará o papel de hypervisor, como

exibido na figura 5.

Figura 5: Linux KVM

Um processo normal, rodando em Linux, possui dois modos de execução:

Kernel Mode (modo kernel) e User Mode (modo usuário). Porém, por uma máquina

virtual precisar de mais prioridade do que um processo normal, e por ser, também,

bem mais complexa que um aplicativo comum, é adicionado um terceiro modo de

execução: O guest mode (modo Convidado).

Na terminologia KVM, os guests são máquinas virtuais comuns, e o

privileged-guest é a máquina destinada ao gerenciamento, equivalente ao Dom0 do

Xen.

Uma das vantagens ao modelo com um hypervisor tradicional é que o

KVM é um sistema enxuto e minimalista. Sua programação consiste em apenas

alguns milhares de linhas de código. E, como módulo do kernel, é possível

manipulá-lo em tempo de execução, como se fosse um dispositivo qualquer. Seus

guests tem acesso a todo sistema de memória através de chamadas de hardware ou

32

mesmo de DMA12 (DMA: Direct Memmory Access - Acesso direto a memória). E, o

acesso dos guests ao resto do hardware é ilimitado.

Assim como o Xen, o KVM também utiliza o QEMU para promover a

abstração de hardware na máquina virtual. Assim, exceto o processador, o hardware

simulado é o mesmo do QEmu

4.3.1 Componentes do KVM

Os dois componentes principais do KVM são explicados abaixo:

- Um driver de dispositivos para gerenciamento do hardware virtualizador.

Este driver trabalha utilizando o dispositivo /dev/kvm.

- Um componente no user-space para emulação do hardware de um PC

comum. Para isso, é utilizada uma versão modificada do QEMU.

O QEmu modificado roda como processo no sistema, e cria uma camada

de hardware para a máquina virtual, mapeando a memória física e as chamadas do

kernel (especificamente do módulo KVM) para a execução do guest. O I/O das

máquinas virtuais é diretamente derivado do QEMU, onde existe o suporte a todos

os tipos de imagem de disco que o mesmo oferece.

4.3.2 Gerenciamento

A partir do ponto que uma máquina virtual é simplesmente um processo,

todas as ferramentas de gerenciamento de processo do sistema Linux são

reaproveitadas. É possível pausar, desligar e restaurar uma máquina virtual

diretamente com o comando kill (ou usando os atalhos de teclado, como CTRL + C e

12 DMA: Direct Memmory Access - Acesso direto a memória. Provê acesso a memória sem a necessidade de interrupção da CPU.

33

CTRL + Z), assim como é possível verificar a alocação de recursos com o comando

top.

4.4 VMWARE SERVER

Segundo o VMware Server Product Datasheet, o mesmo é instalado como

aplicação no topo de um sistema operacional host, seja ele Windows ou Linux, e cria

um hypervisor que traduz as chamadas do sistema guest para o host. Os recursos

de um mesmo servidor físico são tratados e distribuídos uniformemente entre todas

as máquinas virtuais.

O pseudo-hardware virtual criado pelo VMware para abstração dos guests

constituído dos seguintes ítens:

- Placa de rede AMD PCnet32 Accelerated

- Placa de som Ensoniq ES1371 WDM

- Controladora SCSI a escolher (LSI Logic ou BusLogic)

- Chipset Intel 430VX

O VMware também instala drivers adicionais no sistema operacional guest

e host para otimizar o acesso dos recursos nas máquinas físicas e virtuais. Na

máquina guest, esses drivers são conhecido como VMware Tools, e conclui a

instalação dos dispositivos faltantes (driver de vídeo, por exemplo).

4.4.1 Novos recursos no VMware Server 2

Com o VMware Server 2, novos recursos foram adicionados; Ele oferece

suporte aos sistemas operacionais Windows Server 2008, Windows Vista, RedHat

Enterprise Linux 5 e Ubuntu 8.04. Foi acrescentado o suporte aos sistemas

operacionais 64 bits (caso o hardware seja 64 bits) para Linux de mesma

arquitetura.

34

Foi incluída, também, uma nova interface web para gerenciamento das

máquinas virtuais. E este serviço de virtualização, oferecido pelo VMware Server,

também pode ser acessado através do software VMware Virtual Infrastructure Client,

que unifica o acesso a plataformas de virtualização da mesma empresa.

O VMware Server também oferece recursos para que as máquinas virtuais

possam ter até 8GB de memória RAM, 10 interfaces de rede virtuais, USB 2.0 e

duas opções de discos SCSI.

4.5 VMWARE ESX SERVER

Segundo o VMware ESX 3.5 Product Datasheet, o VMware ESX Server foi

criado para possibilitar a criação de um ambiente de TI virtual, dinâmico e otimizado;

Ele é um sistema operacional, baseado no kernel Linux, que cria uma camada de

abstração para acesso aos recursos do sistema (processadores, memórias,

storages13 e dispositivos de rede) por máquinas virtuais.

Por ser um sistema operacional completo, o VMware ESX é instalado

diretamente no hardware (bare-metal14) do servidor, e traz consigo seu hypervisor

(denominado VMkernel), que provê os recursos para execução das máquinas

virtuais. Assim, ele precisa ser acessado através do software VMware Virtual

Infrastructure Client para que possam ser criadas as configurações no mesmo

servidor;

13 Storage: Equipamento que agrega determinadas quantidades de HDs de alta perfomance para serem acessados através do meio externo, muitas vezes através de múltiplos servidores; 14 Bare-metal: “Metal nu” (tradução livre); Instalado diretamente no equipamento;

35

4.5.1 VMware ESXi

Com base no VMware ESX, a VMware lançou a versão gratuita do

produto, o VMware ESXi Server; O ESXi não possui os recursos de VMotion (live

migration) nem suporte da empresa, mas pode ser utilizado gratuitamente. Recursos

adicionais, como o próprio VMotion, podem ser comprados adicionalmente e

inseridos no VMware ESXi.

O VMware ESXi também possui uma versão embbeded15 chamada

VMware ESXi Small Footprint, de apenas 32MB, que está sendo integrada em várias

placas mães de servidores de terceiros, fabricados por empresas parceiras da

VMware.

4.6 VMWARE WORKSTATION

Solução de virtualização para desktops da VMware, o mesmo é instalado

como aplicação no topo de um sistema operacional host, seja ele Windows ou Linux,

e cria um hypervisor que traduz as chamadas do sistema guest para o host, tal qual

ao VMware Server. Porém, esta versão é utilizada para desenvolvimento e para

testes de aplicativos locais, e não para uso em produção.

4.7 SUN XVM,

O xVM (anteriormente chamado "Virtualbox") é um virtualizador completo,

que utiliza partes do QEMU e do BOCHS como base para seu funcionamento

(incrementando outros recursos), e é destinado a virtualização de sistemas

operacionais na plataforma x86. Atualmente o Sun xVM roda nativamente nos

sistemas operacionais Windows, Linux, Mac OS X e OpenSolaris.

15 Embedded: Embarcado;

36

O xVM também suporta tecnologias de virtualização via hardware, tanto da

Intel (Intel VT) quanto da AMD (AMD-V). A utilização dessas tecnologias de

virtualização é opcional para cada maquina virtual, podendo ser incluída/removida

facilmente. Porém, ela é necessária nos seguintes casos:

- Ao virtualizar um sistema operacional raro, como o IBM OS/2, que desde

sua concepção (apesar de descontinuado desde 1996) utiliza instruções complexas

da plataforma x86 que não são suportadas com virtualização diretamente em

software.

- Ao virtualizar um sistema operacional guest com suporte a 64 bits.

4.7.1 Suporte a guests

O xVM pode executar todos os sistemas operacionais x86 como por

exemplo DOS, Windows (todas as versões para x86) , FreeBSD, OpenBSD, Linux e

Solaris.

4.8 QUADRO COMPARATIVO DAS FERRAMENTAS

O quadro a seguir exibe uma comparação entre as ferramentas utilizadas na

virtualização destacando as principais características de cada uma delas.

37

FERRAMENTA DESENVOLVEDOR PLATAFORMA OPERACIONAL

SISTEMAS OPERACIONAIS SUPORTADOS

TECNOLOGIAS UTLIZADAS

QEmu Fabrice Bellard x86, PowerPc

-Windows -MS Dos -Linux e Unix (FreeBSD, NetBSD, Solaris) - etc.

Emulação de Hardware e Virtualização Completa

XEN Hypervisor Citrix Technologies x86

-Linux -NetBSD -Solaris -Windows

Paravirtualização e Virtualização completa

VMware Server VMware Inc. x86

-Linux -Windows -Unix

Virtualização Completa

VMware ESX/ESXi

Server:

VMware Inc. x86 -Linux -Windows -Unix

Paravirtualização16 e Virtualização completa

Linux KVM RedHat17 x86

-Linux, -Windows -Unix (FreeBSD e Solaris)

Virtualização Completa18

16 A Paravirtualização no VMware ESX/ESXi se aplica apenas a guests com sistema Linux. 17 RedHat: A RedHat adquiriu a Qumranet, desenvolvedora original do KVM em 4 de setembro de 2008. 18 Está sendo adicionado recurso de paravirtualização ao KVM.

38

5 EXPERIMENTOS E RESULTADOS

5.1.1 Descrição do Ambiente

Foi instalado na máquina física o sistema operacional CentOS 5.2 Linux

64 bits, com kernel 2.6.18, e 3GB de memória Ram, sendo que desta memória, 1GB

foi destinado inteiramente para a máquina virtual em execução. Devido a

divergências de cada uma das tecnologias, cada máquina virtual foi executada

individualmente. O processador utilizado foi um Intel Core 2 Duo E6420, sendo

disponibilizados apenas um núcleo para as máquinas virtuais. Foi utilizada uma

partição com 49GB em um HD de 160GB, destinando 8GB para cada máquina

virtual.

As tarefas designadas para cada servidor virtualizado, na criação de um

ambiente de produção, foram máquinas virtuais configuradas adequadamente com

as finalidades de testar o desempenho individual com softwares para benchmark,

codificação de vídeo e testes com aplicativos simulando servidores reais.

5.1.2 Análise de Desempenho

Cada máquina foi submetida a testes de processamento, de I/O e de

conectividade, analisando a performance de cada uma como um todo. As tarefas

submetidas foram:

a) Codificação de vídeo utilizando o software Transcode;

b) Análise de performance geral com o software LMBench.

c) Transferência de arquivo com 4GB via NFS (cliente Linux) e SMB (cliente

Windows);

d) Inundação de requisições simultâneas para o servidor web utilizando o

software AB (Apache Benchmark).

39

Todos os testes do tipo cliente/servidor realizados (transferência de arquivos

e benchmark com AB) foram executados a partir de outro host na rede, utilizando o

sistema operacional Microsoft Windows XP SP3 para transferência de arquivos via

SMB, e o sistema operacional Fedora Linux versão 8 para transferência de arquivos

por NFS. A inundação de requisições para os servidores Apache de cada máquina

virtual, realizada pelo AB, também foi feita a partir deste host Linux. A rede entre as

duas máquinas foi estabelecida através de um switch Encore 3NH908, operando a

100Mbps em modo full duplex.

Os testes de performance individuais (como a codificação de vídeo e análise

de desempenho com o LMBench) foram realizados com o sistema operacional host

em IDLE19, evitando assim a influencia nos testes de cada uma delas.

5.2 LMBENCH

A execução do LMBench versão 3 Alpha, nas máquinas virtuais testou os

seguintes itens em cada uma delas:

- Manipulação de Processos;

- Operações com números do tipo integer - inteiro;

- Operações com números do tipo float – ponto flutuante;

- Operações com números do tipo double – números duplos;

- Context Switching – Troca de Contexto;

- Latência de comunicação local;

- Latência em sistema de arquivos (e manipulação destes) e memória

virtual;

- Largura de banda para comunicação local;

- Latência de memória.

19 IDLE: Stand-By. Equipamento em espera sem aplicação específica em operação.

40

O detalhamento completo de cada um dos subtestes realizados pode ser

obtido, em uma máquina com o sistema operacional Linux que possua o LMBench

instalado, através do comando man lmbench, e não é o objetivo deste documento. O

LMBench foi executado por aproximadamente 26 horas em cada máquina virtual até

a obtenção do resultado. O resultado escrito devolvido pelo LMBench em cada host

está anexo neste documento.

A versão utilizada era a última disponível nos repositórios da distribuição

adotada pelo grupo, e apesar de ser uma versão Alpha, não foi demonstrado

qualquer sinal de instabilidade durante toda a realização dos testes citados.

5.2.1 Manipulação de Processos

O Gráfico 1 abaixo representa o comparativo entre o tempo de

manipulação de processos em cada máquina virtual. Quanto menor o resultado

obtido, maior a eficiência do virtualizador.

41

Gráfico 1 - Comparativo de Processos

5.2.2 Operações com Números Inteiros

O Gráfico 2 representa o comparativo de tempo para realização de cada

uma das operações descritas utilizando números inteiros. Quanto menor o resultado

obtido, maior a eficiência em cada máquina virtual.

42

Gráfico 2 - Operações com Inteiros

5.2.3 Operações com Números fracionários ( Floats)


uma das operações descritas utilizando números fracionados (tipo float). Quanto

menor o resultado obtido, maior a eficiência em cada máquina virtual.

43

Gráfico 3 - Operações com Floats

44

5.2.4 Operações com Números Dobrados ( Double)


uma das operações descritas utilizando números dobrados (tipo double). Quanto


Gráfico 4 - Operações com Doubles

45

5.2.5 Context Switching – Troca de Contexto

O Gráfico 5 abaixo representa o comparativo de tempo para realização de

troca de contexto em cada uma das operações descritas. Quanto menor o resultado

obtido, maior a eficiência em cada máquina virtual.

Gráfico 5 - Context Switching

46

5.2.6 Latência para Comunicação Local

O Gráfico 6 representa o comparativo de latência para comunicação local.

Quanto menor o resultado obtido, maior a eficiência em cada máquina virtual.

Gráfico 6 - Latência de Comunicação Local

5.2.7 Latência de sistema de arquivos

O Gráfico 7 representa o comparativo de sistema de arquivos. Quanto


47

Gráfico 7 - Latência de Sistema de Arquivos

5.2.8 Largura de banda para comunicação local

O Gráfico 8 representa o comparativo entre a largura de banda para

comunicação local de cada máquina virtual. Quanto maior o resultado obtido, maior

a eficiência em cada virtualizador.

48

Gráfico 8 - Largura de Banda para Comunicação Local

5.2.9 Latência de Memória

O Gráfico 9 representa o comparativo entre a latência de memória de cada

máquina virtual. Quanto menor o resultado obtido, maior a eficiência em cada

virtualizador.

49

Gráfico 9 - Comparativo de Latência de memória

5.2.10 Média de Latência de Memória

O Gráfico 10 representa o comparativo entre a latência média de memória

de cada máquina virtual. Este dado é exibido imediatamente após a finalização da

execução do LMBench. Quanto menor o resultado obtido, maior a eficiência em

cada virtualizador.

50

Gráfico 10 - Média de Latência de Memória

5.3 TRANSFERÊNCIA DE ARQUIVOS

Foi realizada cópia de uma imagem de DVD com 4GB através de um host de

rede, utilizando NFS (cliente Linux) e posteriormente Samba (cliente Windows).

51

5.3.1 SMB

Utilizando o Samba não houve diferença de performance entre os três

virtualizadores. A imagem foi transferida do servidor virtualizado para o cliente

Windows físico em 12 minutos.

5.3.2 NFS

Ocorreu diferença de tempo ao realizar a transferência da mesma imagem de

DVD a partir do servidor virtualizado para o cliente Linux físico. O Gráfico 11

demonstra o tempo que cada uma das ferramentas demorou para realizar a cópia do

arquivo. O log da STDOUT20 durante a transferência do arquivo está anexo neste

documento.

20 STDOUT: Fluxo padrão de saída de texto no sistema operacional Linux. Exibido na tela por padrão.

52

Gráfico 11 - Transferência de Arquivos em NFS

5.4 CODIFICAÇÃO DE VÍDEO

Foi realizada a codificação de um vídeo com 55 minutos e 439MB, alterando a

resolução para 800x362 e convertendo para o formato DivX utilizando o software

transcode. Houve diferença de performance entre os virtualizadores, e o log da

STDOUT está anexo neste documento.

53

Gráfico 12 - Codificação de vídeo

5.5 BENCHMARK DE SERVIDOR WEB

O AB faz parte da suíte Apache Web Server, e é recomendado para

realização de benchmarks de servidores web. Utilizando-o, foram realizadas duas

sessões de testes no servidor Apache de cada máquina virtual: Ambas com o total

de 200.000 requisições. Porém, na primeira sessão foram disparadas 100

54

solicitações simultâneas por rajada, e na segunda sessão, 200 solicitações

simultâneas por rajada.

5.5.1 100 requisições por rajada

Os Gráficos 13 e 14 comparam os tempos obtidos durante a realização da

primeira sessão dos testes com o AB. Quanto menor a quantidade de tempo para

atendimento de cada requisição, melhor a eficiência do virtualizador. Os logs com as

STDOUTs das sessões dos três virtualizadores, que originaram os gráficos, estão

anexos no documento.

Na análise a seguir, o gráfico 13 e 15 (Connection Times) analisa os

seguintes aspectos:

- Connect: Tempo estimado gasto para começar a atender a conexão.

- Proccessing: Tempo estimado gasto para realizar o processamento de

cada uma das conexões.

- Waiting: Tempo de espera gasto entre o último bit de requisição ser

enviado do cliente, e o primeiro bit de resposta do servidor ser disparado para

atendê-lo.

- Total: Tempo total para atender a requisição.

Gráfico 13 - Connection Times para 100 requisições por rajada

Gráfico 14 - Porcentagem de Requisições por Tempo

57

5.5.2 200 requisições por rajada

Os Gráficos 15 e 16 agora comparam os tempos obtidos durante a realização

da segunda sessão dos testes com o AB. Quanto menor a quantidade de tempo

para atendimento de cada requisição, melhor a eficiência do virtualizador. Os logs

com as STDOUTs das sessões dos três virtualizadores, que originaram os gráficos,

também estão anexos no documento.

O detalhamento de cada modalidade foi citado no item 5.5.1.

Gráfico 15 - Connection Times para 200 requisições por rajada

Gráfico 16 - Porcentagem de Requisições por Tempo

60

6 CONSIDERAÇÕES FINAIS

O VMware Server 2 obteve desempenho equilibrado nas modalidades

testadas pelo LMBench, mas demonstrou excelente performance ao trabalhar com

arquivos grandes em rede. O mesmo também possui a melhor interface de

administração, que pode ser acessada através do browser e garante a mesma

funcionalidade do VMware Virtual Infrastructure Client, aplicação desktop da

VMware Inc. para gerenciamento unificado das plataformas da empresa.

O KVM apresentou uma grande diferença entre os resultados obtidos para

uso em produção e através da comparação de desempenho. Ele se sobressaiu em

quase todas as modalidades do LMBench mas deixou a desejar no uso em

produção, demorando mais tempo que os outros virtualizadores em quase todos os

testes realizados, principalmente no que tange a comunicação em rede. Este

problema aparenta ser causado pelo legado de rede contido no código do QEMU,

utilizado para criação de dispositivos na máquina virtual. Porém, por ser o mais

recente de todas as ferramentas testadas, mostrou estar no caminho certo para

obter boa competência no futuro.

A versão utilizada do Xen foi a 3.0.3, a última disponível no repositório da

distribuição escolhida pelo grupo para realização dos testes. A última versão do Xen

é a 3.3.0, que segundo o lançamento oficial, realizou grande avanço na parte de

comunicação de rede e I/O. Os resultados alcançados poderiam ser diferentes caso

a versão utilizada fosse a mais recente. Porém, esta versão ainda não foi

considerada estável pelos desenvolvedores da distribuição adotada pelo grupo, e

por isso não foi utilizada. Apesar disso, o Xen obteve os melhores resultados para

uso em produção comparado as outras ferramentas.

61

6.1 DIFICULDADES ENCONTRADAS

Os testes originalmente foram planejados utilizando configurações de

hardware virtual diferentes das apresentadas neste documento: Cada máquina

virtual, de acordo com o projeto original, funcionaria com dois processadores lógicos,

onde os resultados apresentados seriam diferentes dos expostos neste documento.

Porém, o KVM demonstrou não suportar corretamente as máquinas

virtuais com mais de um processador, e com a máquina virtual uma vez configurada

para utilizar dois processadores lógicos (SMP21), a mesma se tornava instável e

imprópria para uso comum, uso em produção e para realização de qualquer outro

teste. De modo que, quando a máquina virtual não carregava incorretamente o

sistema operacional, o sistema guest travava devolvendo o chamado Kernel Panic

após alguns minutos de uso banal.

O Kernel Panic é a falha irrecuperável de um sistema operacional Unix ou

Linux. Ela, geralmente, é apresentada em caso de falha de hardware (nesse caso,

virtual) ou exceção não tratada pelo sistema operacional.

Este comportamento foi relatado utilizando tanto a distribuição oficial

adotada (CentOS Linux 5.2 com kernel 2.6.18) quanto em outra distribuição sem

finalidades acadêmicas e inapropriada para testes realizados (Fedora 9 com kernel

2.6.25).

Por esse motivo, os testes que já haviam sido realizados com dois

processadores tanto no VMware Server quanto no Xen, foram descartados visando

a imparcialidade da comparação entre todas as ferramentas. Após o downgrade de

processador nas máquinas virtuais do Xen e do VMware Server, os testes foram

refeitos e a máquina virtual executada pelo KVM funcionou perfeitamente, sem

nenhuma das instabilidades antes apresentadas.

21 SMP: Symmetric Multi-Proccessing - Multi-processamento simétrico, procedimento que utiliza duas ou mais CPUs.

62

O planejamento inicial deste documento também previa a utilização do

VMware ESXi Server como ferramenta da VMware Inc. em substituição ao VMware

Server. Porém, o VMware ESXi Server tem como exigência uma lista de hardware

compatível (HCL22) homologada pela empresa, e não foi possível a execução do

VMware ESXi Server no equipamento utilizado nos testes, pelo fato do hardware

pelo possuído pelo grupo ter pouquíssima similaridade com o exigido para o produto.

Por este motivo, foi utilizado o VMware Server 2 representando as ferramentas da

VMware Inc., e que se demonstrou bastante estável durante toda a bateria de testes

que o grupo realizou.

6.2 LIMITAÇÕES

Devido ao hardware utilizado para o ambiente de teste ser um computador

montado da plataforma x86, só foram testadas ferramentas que funcionam na

referida plataforma. Existem outras ferramentas de virtualização para uso específico,

de propriedade de empresas como a Sun e a IBM. Como, por exemplo, os

Conteiners e Zones, do sistema operacional Solaris, ou as LPars do sistema

operacional AIX.

6.3 EXPERIMENTOS FUTUROS

Fica para um próximo experimento a realização dos mesmos testes

utilizando um servidor de marca compatível com a HCL dos produtos VMware ESX

Server e VMware ESXi Server, da VMware Inc., que são mais apropriados que o

VMware Server para a utilização em data-centers.

22 HCL:Hardware Compatible List – Lista de Hardware Compatível.

63

6.4 CONCLUSÕES

Após abordada a origem da virtualização, foram realizados testes de

desempenho em máquinas virtuais análogas em hardware e software, mantendo sua

diferença apenas no virtualizador: Xen, VMware Server e Linux KVM.

Os resultados obtidos denotaram, para a maioria das modalidades

testadas, a proximidade de desempenho entre cada uma das ferramentas de

virtualização utilizadas neste documento.

Isso demonstra que, com o atual avanço no suporte à virtualização via

hardware através das extensões Intel VT e AMD-V, e que são utilizadas pelos três

virtualizadores, a proximidade entre as três ferramentas é bastante evidente. Ambas

as ferramentas analisadas se sobressaíram em determinados testes, e o grupo

elegeu ao Xen como melhor custo x benefício para virtualização de servidores

dentre os analisados. Porém, cabe ao administrador de sistemas escolher a que

mais lhe aprouver.

64

REFERÊNCIAS BIBLIOGRÁFICAS

APR Soluções. Disponível em: http://www.compaq.com.br/pyme/solucoes/apr_solucoes_01.html. Acesso em: 21set.2008. ATLAS Computer (Manchester). Disponível em: http://en.wikipedia.org/wiki/Atlas_Computer_(Manchester). Acesso em: 30 set.2008. CAMBRIDGE, U.K. A State of Xen: Virtualization from PDAs to Super Computers . [2008]. Disponível em: <http://citrix.com/English/NE/news/news.asp?newsID=1680834>. Acesso em: 12 nov.2008. GOLDEN, Bernard; SCHEFFY, Clark. Virtualization for Dummies, Sun AMD Special Edition. Indianapolis: Wiley Publishing INC, 2008. GOMES, Lee. VMware Brings Freedom of Choice to Your Desktop. [1999]. Disponível em: <http://www.vmware.com/company/news/articles/wsj_1.html>. Acesso em: 14 out.2008. HADDON, Tom. Hardware emulation with QEMU . [2005]. Disponível em: <http://www.linux.com/feature/49225>. Acesso em: 06 out.2008. JONES, M. Tim. Virtual Linux. [2006]. Disponível em: <http://www-128.ibm.com/developerworks/linux/library/l-linuxvirt/?ca=dgr-lnxw01Virtual-Linux>. Acesso em: 01ago.2008. KVM kernel-based Virtualization driver. Disponível em: http://docs.huihoo.com/kvm/kvm-white-paper.pdf. Acesso em: 21 set.2008. MOREIRA, Daniela. Virtualização: rode vários sistemas operacionais na mesma máquina. [2006]. Disponível em: <http://idgnow.uol.com.br/computacao_corporativa/2006/08/01/idgnoticia.2006-07-31.7918579158/IDGNoticiaPrint_view/>. Acesso em: 21 set.2008. NSPLUGINWRAPPER. Disponível em: http://gwenole.beauchesne.info/en/projects/nspluginwrapper. Acesso em: 08 out.2008. OITO principais desafios da virtualização de data centers. Disponível em: http://idgnow.uol.com.br/computacao_corporativa/2007/04/27/idgnoticia.2007-04-27.3291222006/IDGNoticiaPrint_view/. Acesso em: 21 out.2008. SINGH, Amit. Na Introduction to Virtualization . [2008]. Diponível em: <http://www.kernelthread.com/publications/virtualization/>. Acesso em: 21 set.2008.

65

SIQUEIRA, Luciano; BRENDEL, Jeans-Chistoph. Linux Pocket Pro – Virtualização . São Paulo: Linux New Media, 2007. SUN xVM Virtualbox. Disponível em: http://download.virtualbox.org/virtualbox/2.0.4/UserManual.pdf. Acesso em: 12 out.2008. VIRTUALIZAÇÃO de Servidores. Disponível em: http://www.intel.com/portugues/business/technologies/virtualization.htm. Acesso em: 21 set.2008. VIRTUALIZATION history. Disponível em: http://www.vmware.com/overview/history.html. Acesso em: 30 set.2008. VMWARE Datasheet ESXI. Disponível em: http://www.vmware.com/files/pdf/vmware_esxi_datasheet.pdf. Acesso em: 12 out.2008. VMWARE Server. Disponível em: http://www.vmware.com/br/pdf/server_datasheet_br.pdf. Acesso em: 12 out.2008. XEN Interface’s Manual. Disponível em: http://www.xen.org/files/xen_interface.pdf . Acesso em: 12 set.2008. XEN Manual do usuário. Disponível em: http://bits.xensource.com/Xen/docs/user.pdf . Acesso em: 12 set.2008.

66

ANEXO A: ARQUIVO DE CONFIGURAÇÃO PARA INSTALAÇÃO CO M XEN

Tal arquivo de configuração foi usado para instalação CentOS 5.2 no Xen.

Primeiramente foram criado os HDs virtuais, com o comando:

# dd if=/dev/zero of=/var/xen/Domain1.img bsize=1G B count=8 # dd if=/dev/zero of=/var/xen/Domain1swap.img bsi ze=1024 count=512

Depois, foi elaborado um arquivo de configuração para efetuar a

instalação do CentOS como DomainU paravirtualizado do Xen.

kernel = "/mnt/cdrom/xen/vmlinuz" ramdisk = "/mnt/cdrom/xen/initrd.img" memory = "1024" name = "Domain1" disk = ['file:/var/xen/Domain1.img,xvda,w', 'file:/var/xen/Domain1swap.img,xvdb,w'] root = '/dev/xvda1 ro' vif = [ 'bridge=xenbr0' ] vcpus = 2 vfb = [ 'type=vnc, vncunused=1' ] extra = 'video=xenfb'

Então, esse arquivo foi salvo com o nome de “Domain1-inst.conf”. Após

isso, ele foi inicializado com o comando:

# xm create –c Domain1-inst.conf

67

ANEXO B: ARQUIVO DE CONFIGURAÇÃO APÓS A INSTALAÇÃO COM XEN

Após instalação do sistema operacional, foi criado um novo arquivo de

configuração para o host para que este fosse inicializado.

memory = "1024" bootloader = "/usr/bin/pygrub" name = "Domain1" disk = ['file:/var/xen/Domain1.img,xvda,w', 'file:/var/xen/Domain1swap.img,xvdb,w'] root = '/dev/xvda1 ro' vif = [ 'bridge=xenbr0' ] vcpus = 1 vfb = [ 'type=vnc, vncunused=1' ] extra = 'video=xenfb'

Então, esse arquivo foi salvo com o nome de “Domain1-post-inst.conf”.

Após isso, ele foi startado com o comando:

# xm create –c Domain1-post-inst.conf

68

ANEXO C: CRIAÇÃO DE MÁQUINA VIRTUAL COM KVM

Procedimento adotado para instalação do CentOS na máquina virtual do

Linux KVM. Primeiramente foi ativado o módulo responsável pela virtualização:

# modprobe kvm # modprobe kvm_intel

Após isso, foram criados os HDs virtuais, com os comandos:

# dd if=/dev/zero of=/var/kvm/hd01.img bsize=1GB c ount=8 # dd if=/dev/zero of=/var/kvm/swap.img bsize=1024 count=512

Por último, foi executado o software com a linha:

# QEmu-kvm -usb -hda /var/kvm/hd01.img -hdb \

/var/kvm/swap.img -boot c -net nic \

-net tap,script=/etc/QEmu-kvm-ifup -m 1024 -smp 1

69

ANEXO D: REDE BRIDGE DO QEMU-KVM

Criado o script /etc/QEmu-kvm-ifup com a seguinte configuração:

#!/bin/sh set -x switch=virbr0 if [ -n "$1" ];then /usr/sbin/tunctl -u `whoami` -t $1 /sbin/ip link set $1 up sleep 0.5s /usr/sbin/brctl addif $switch $1 exit 0 else echo "Error: no interface specified" exit 1 fi

Essa configuração bastou para que a máquina virtual KVM adquirisse um

IP e comunicação com a rede externa, a mesma da máquina física.

70

ANEXO E: SAÍDA DE EXECUÇÃO DO LBENCH NO KVM

L M B E N C H 3 . 0 S U M M A R Y ---------------------------------- -- (Alpha software, do not distribute) Basic system parameters --------------------------------------------------- --------------------------- Host OS Description Mh z tlb cache mem scal pages line par load bytes --------- ------------- ----------------------- --- - ----- ----- ------ ---- KVM.timm. Linux 2.6.18- x86_64-linux-gnu 213 6 8 128 1.3000 1 Processor, Processes - times in microseconds - smal ler is better --------------------------------------------------- --------------------------- Host OS Mhz null null open sl ct sig sig fork exec sh call I/O stat clos TC P inst hndl proc proc proc --------- ------------- ---- ---- ---- ---- ---- -- -- ---- ---- ---- ---- ---- KVM.timm. Linux 2.6.18- 2136 0.38 0.44 1.41 2.36 4. 15 0.51 9.58 1066 2960 7714 Basic integer operations - times in nanoseconds - s maller is better --------------------------------------------------- ---------------- Host OS intgr intgr intgr intgr intgr bit add mul div mod --------- ------------- ------ ------ ------ ------ ------ KVM.timm. Linux 2.6.18- 0.5000 0.0100 0.2300 16.5 10.3 Basic uint64 operations - times in nanoseconds - sm aller is better --------------------------------------------------- --------------- Host OS int64 int64 int64 int64 int64 bit add mul div mod --------- ------------- ------ ------ ------ ------ ------ KVM.timm. Linux 2.6.18- Basic float operations - times in nanoseconds - sma ller is better --------------------------------------------------- -------------- Host OS float float float float add mul div bogo --------- ------------- ------ ------ ------ ------ KVM.timm. Linux 2.6.18- 1.4800 2.0000 10.2 8.4800 Basic double operations - times in nanoseconds - sm aller is better --------------------------------------------------- --------------- Host OS double double double doubl e add mul div bogo --------- ------------- ------ ------ ------ ----- - KVM.timm. Linux 2.6.18- 1.4700 2.4900 17.0 15.5 Context switching - times in microseconds - smaller is better --------------------------------------------------- ---------------------- Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw --------- ------------- ------ ------ ------ ------ ------ ------- ------- KVM.timm. Linux 2.6.18- 4.5600 5.0800 4.6800 5.9200 5.4000 5.71000 6.20000

71

*Local* Communication latencies in microseconds - s maller is better --------------------------------------------------- ------------------ Host OS 2p/0K Pipe AF UDP RPC / TCP RPC/ TCP ctxsw UNIX UD P TCP conn --------- ------------- ----- ----- ---- ----- ---- - ----- ----- ---- KVM.timm. Linux 2.6.18- 4.560 11.1 19.1 23.1 29. 6 28.1 34.2 83. *Remote* Communication latencies in microseconds - smaller is better --------------------------------------------------- ------------------ Host OS UDP RPC/ TCP RPC/ TCP UDP TCP con n --------- ------------- ----- ----- ----- ----- --- - KVM.timm. Linux 2.6.18- File & VM system latencies in microseconds - smalle r is better --------------------------------------------------- ---------------------------- Host OS 0K File 10K File Mmap Prot Page 100fd Create Delete Create Delete Latency Fault Fault selct --------- ------------- ------ ------ ------ ------ ------- ----- ------- ----- KVM.timm. Linux 2.6.18- 10.8 5.7202 30.0 13.4 27.5K 3.798 12.1 2.258 *Local* Communication bandwidths in MB/s - bigger i s better --------------------------------------------------- -------------------------- Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem UNIX reread rerea d (libc) (hand) read write --------- ------------- ---- ---- ---- ------ ----- - ------ ------ ---- ----- KVM.timm. Linux 2.6.18- 1789 911. 1210 2102.2 3353. 8 718.3 723.1 2604 842.5 Memory latencies in nanoseconds - smaller is better (WARNING - may not be correct, check graphs) --------------------------------------------------- --------------------------- Host OS Mhz L1 $ L2 $ Main mem Rand mem Guesses --------- ------------- --- ---- ---- ---- ---- -------- ------- KVM.timm. Linux 2.6.18- 2136 1.4740 6.8950 87.2 164.7 x86_64-linux-gnu: lat_mem_rand = 164.651

72

ANEXO F: SAÍDA DE EXECUÇÃO DO LBENCH NO XEN

L M B E N C H 3 . 0 S U M M A R Y ---------------------------------- -- (Alpha software, do not distribute) Basic system parameters --------------------------------------------------- --------------------------- Host OS Description Mh z tlb cache mem scal pages line par load bytes --------- ------------- ----------------------- --- - ----- ----- ------ ---- Dom01.tim Linux 2.6.18- x86_64-linux-gnu 213 6 7 16 1.1700 1 Processor, Processes - times in microseconds - smal ler is better --------------------------------------------------- --------------------------- Host OS Mhz null null open sl ct sig sig fork exec sh call I/O stat clos TC P inst hndl proc proc proc --------- ------------- ---- ---- ---- ---- ---- -- -- ---- ---- ---- ---- ---- Dom01.tim Linux 2.6.18- 2136 1.35 1.49 3.44 5.79 4. 82 1.27 3.15 755. 2624 5888 Basic integer operations - times in nanoseconds - s maller is better --------------------------------------------------- ---------------- Host OS intgr intgr intgr intgr intgr bit add mul div mod --------- ------------- ------ ------ ------ ------ ------ Dom01.tim Linux 2.6.18- 0.8300 0.0200 0.2700 18.7 9.4300 Basic uint64 operations - times in nanoseconds - sm aller is better --------------------------------------------------- --------------- Host OS int64 int64 int64 int64 int64 bit add mul div mod --------- ------------- ------ ------ ------ ------ ------ Dom01.tim Linux 2.6.18- Basic float operations - times in nanoseconds - sma ller is better --------------------------------------------------- -------------- Host OS float float float float add mul div bogo --------- ------------- ------ ------ ------ ------ Dom01.tim Linux 2.6.18- 1.7100 2.1400 10.3 8.7500 Basic double operations - times in nanoseconds - sm aller is better --------------------------------------------------- --------------- Host OS double double double doubl e add mul div bogo --------- ------------- ------ ------ ------ ----- - Dom01.tim Linux 2.6.18- 1.4600 2.4300 16.6 15.6 Context switching - times in microseconds - smaller is better --------------------------------------------------- ---------------------- Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw --------- ------------- ------ ------ ------ ------ ------ ------- ------- Dom01.tim Linux 2.6.18- 1.5500 3.4200 7.2900 6.9500 8.0500 6.83000 3.46000 *Local* Communication latencies in microseconds - s maller is better --------------------------------------------------- ------------------

73

Host OS 2p/0K Pipe AF UDP RPC / TCP RPC/ TCP ctxsw UNIX UD P TCP conn --------- ------------- ----- ----- ---- ----- ---- - ----- ----- ---- Dom01.tim Linux 2.6.18- 1.550 15.6 37.2 21.6 29. 8 25.2 35.9 82. *Remote* Communication latencies in microseconds - smaller is better --------------------------------------------------- ------------------ Host OS UDP RPC/ TCP RPC/ TCP UDP TCP con n --------- ------------- ----- ----- ----- ----- --- - Dom01.tim Linux 2.6.18- File & VM system latencies in microseconds - smalle r is better --------------------------------------------------- ---------------------------- Host OS 0K File 10K File Mmap Prot Page 100fd Create Delete Create Delete Latency Fault Fault selct --------- ------------- ------ ------ ------ ------ ------- ----- ------- ----- Dom01.tim Linux 2.6.18- 15.0 12.0 61.8 27.9 13.3K 1.516 4.18400 4.054 *Local* Communication bandwidths in MB/s - bigger i s better --------------------------------------------------- -------------------------- Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem UNIX reread rerea d (libc) (hand) read write --------- ------------- ---- ---- ---- ------ ----- - ------ ------ ---- ----- Dom01.tim Linux 2.6.18- 1789 919. 1421 1980.2 3440. 3 693.4 699.1 3183 859.5 Memory latencies in nanoseconds - smaller is better (WARNING - may not be correct, check graphs) --------------------------------------------------- --------------------------- Host OS Mhz L1 $ L2 $ Main mem Rand mem Guesses --------- ------------- --- ---- ---- ---- ---- -------- ------- Dom01.tim Linux 2.6.18- 2136 1.4120 6.7260 78.7 145.6

74

ANEXO G: SAÍDA DE EXECUÇÃO DO LBENCH NO VMWARE SERV ER

L M B E N C H 3 . 0 S U M M A R Y ---------------------------------- -- (Alpha software, do not distribute ) Basic system parameters --------------------------------------------------- --------------------------- Host OS Description Mh z tlb cache mem scal pages line par load bytes --------- ------------- ----------------------- --- - ----- ----- ------ ---- VMWARE.ti Linux 2.6.18- x86_64-linux-gnu 213 6 8 128 1.8800 1 Processor, Processes - times in microseconds - smal ler is better --------------------------------------------------- --------------------------- Host OS Mhz null null open sl ct sig sig fork exec sh call I/O stat clos TC P inst hndl proc proc proc --------- ------------- ---- ---- ---- ---- ---- -- -- ---- ---- ---- ---- ---- VMWARE.ti Linux 2.6.18- 2136 0.41 0.57 2.54 3.80 4. 74 0.63 2.07 1023 2337 5695 Basic integer operations - times in nanoseconds - s maller is better --------------------------------------------------- ---------------- Host OS intgr intgr intgr intgr intgr bit add mul div mod --------- ------------- ------ ------ ------ ------ ------ VMWARE.ti Linux 2.6.18- 0.5500 0.0100 0.2500 19.9 11.1 Basic uint64 operations - times in nanoseconds - sm aller is better --------------------------------------------------- --------------- Host OS int64 int64 int64 int64 int64 bit add mul div mod --------- ------------- ------ ------ ------ ------ ------ VMWARE.ti Linux 2.6.18- Basic float operations - times in nanoseconds - sma ller is better --------------------------------------------------- -------------- Host OS float float float float add mul div bogo --------- ------------- ------ ------ ------ ------ VMWARE.ti Linux 2.6.18- 1.5800 2.1400 10.9 9.2000 Basic double operations - times in nanoseconds - sm aller is better --------------------------------------------------- --------------- Host OS double double double doubl e add mul div bogo --------- ------------- ------ ------ ------ ----- - VMWARE.ti Linux 2.6.18- 1.6400 2.7100 17.9 16.7 Context switching - times in microseconds - smaller is better --------------------------------------------------- ---------------------- Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw --------- ------------- ------ ------ ------ ------ ------ ------- ------- VMWARE.ti Linux 2.6.18- 4.4300 5.8100 4.8400 5.7900 5.4300 5.63000 5.57000 *Local* Communication latencies in microseconds - s maller is better --------------------------------------------------- ------------------

75

Host OS 2p/0K Pipe AF UDP RPC / TCP RPC/ TCP ctxsw UNIX UD P TCP conn --------- ------------- ----- ----- ---- ----- ---- - ----- ----- ---- VMWARE.ti Linux 2.6.18- 4.430 11.9 22.5 26.3 33. 5 32.2 40.9 *Remote* Communication latencies in microseconds - smaller is better --------------------------------------------------- ------------------ Host OS UDP RPC/ TCP RPC/ TCP UDP TCP con n --------- ------------- ----- ----- ----- ----- --- - VMWARE.ti Linux 2.6.18- File & VM system latencies in microseconds - smalle r is better --------------------------------------------------- ---------------------------- Host OS 0K File 10K File Mmap Prot Page 100fd Create Delete Create Delete Latency Fault Fault selct --------- ------------- ------ ------ ------ ------ ------- ----- ------- ----- VMWARE.ti Linux 2.6.18- 29.6 10.8 96.2 370.1 27.4K 0.650 9.38380 2.439 *Local* Communication bandwidths in MB/s - bigger i s better --------------------------------------------------- -------------------------- Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem UNIX reread rerea d (libc) (hand) read write --------- ------------- ---- ---- ---- ------ ----- - ------ ------ ---- ----- VMWARE.ti Linux 2.6.18- 1663 810. 1071 1968.2 3105. 7 718.2 715.0 2909 899.1 Memory latencies in nanoseconds - smaller is better (WARNING - may not be correct, check graphs) --------------------------------------------------- --------------------------- Host OS Mhz L1 $ L2 $ Main mem Rand mem Guesses --------- ------------- --- ---- ---- ---- ---- -------- ------- VMWARE.ti Linux 2.6.18- 2136 1.5300 7.0730 87.9 188.8

76

ANEXO H: SAÍDA DE EXECUÇÃO DA CODIFICAÇÃO DE VIDEO NO KVM

[root@KVM ~]# date ; transcode -y xvid -j 64,0 -Z 800x368 -i /Compartilhada/michael\ w\ smith\ and\ hillsong\ 20 07.avi -o /Compartilhada/final.avi ; date Seg Nov 17 01:55:14 BRST 2008 transcode v1.0.5 (C) 2001-2003 Thomas Oestreich, 20 03-2004 T. Bitterberg, 2004-2008 Transcode Team [transcode] (probe) suggested AV correction -D 0 (0 ms) | AV 0 ms | 0 ms [transcode] auto-probing source /Compartilhada/mich ael w smith and hillsong 2007.avi (ok) [transcode] V: import format | DivX RIFF data, A VI (V=ffmpeg|A=mp3) [transcode] V: import frame | 480x320 1.50:1 [transcode] V: clip frame (<-) | 480x192 [transcode] V: zoom | 800x368 1.30:1 ( Lanczos3) [transcode] V: bits/pixel | 0.245 [transcode] V: decoding fps,frc | 25.000,3 [transcode] V: Y'CbCr | YV12/I420 [transcode] A: import format | 0x55 MPEG laye r-3 [22050,16,2] 96 kbps [transcode] A: export format | 0x55 MPEG laye r-3 [22050,16,2] 128 kbps [transcode] V: encoding fps,frc | 25.000,3 [transcode] A: bytes per frame | 3528 (3528.000000 ) [transcode] A: adjustment | 0@1000 [transcode] V: IA32/AMD64 accel | sse2 (sse2 sse mm xext mmx asm C) [transcode] V: IA32/AMD64 accel | using sse2 memcpy [transcode] V: video buffer | 10 @ 800x368 [import_mp3.so] v0.1.4 (2003-08-04) (audio) MPEG [import_ffmpeg.so] v0.1.13 (2007-10-09) (video) ffm peg: MS MPEG4v1-3/MPEG4/MJPEG [export_xvid4.so] v0.0.6 (2007-08-11) (video) XviD 1.0.x series (aka API 4.0) | (audio) MPEG/AC3/PCM [import_mp3.so] MP3->PCM [import_mp3.so] tcextract -a 0 -i "/Compartilhada/m ichael w smith and hillsong 2007.avi" -x mp3 -d 0 | tcdecode -x mp3 -d 0 -z 120 00 [export_xvid4.so] Neither './xvid4.cfg' nor '~/.tra nscode/xvid4.cfg' [export_xvid4.so] found. Default settings will be u sed instead. Audio: using new version Audio: using lame-3.98.2 [encoder.c] Delaying audio (0) [mpeg4 @ 0x2aaaace36410]overreading 9 bitss, EMT: 0 :00:30, ( 0| 0| 9) [mpeg4 @ 0x2aaaace36410]concealing 600 DC, 600 AC, 600 MV errors encoding frames [000000-082479], 21.85 fps, EMT: 0 :54:59, ( 0| 0| 4) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 82480 frames (0 dropped, 0 clon ed), clip length 3299.20 s Seg Nov 17 02:58:09 BRST 2008 You have new mail in /var/spool/mail/root [root@KVM ~]#

77

ANEXO I: SAÍDA DE EXECUÇÃO DA CODIFICAÇÃO DE VIDEO NO XEN

[root@Dom01 Compartilhada]# date ; transcode -y xvi d -j 64,0 -Z 800x368 -i /Compartilhada/michael\ w\ smith\ and\ hillsong\ 20 07.avi -o /Compartilhada/final.avi ; date Dom Nov 16 23:47:40 BRST 2008 transcode v1.0.5 (C) 2001-2003 Thomas Oestreich, 20 03-2004 T. Bitterberg, 2004-2008 Transcode Team [transcode] (probe) suggested AV correction -D 0 (0 ms) | AV 0 ms | 0 ms [transcode] auto-probing source /Compartilhada/mich ael w smith and hillsong 2007.avi (ok) [transcode] V: import format | DivX RIFF data, A VI (V=ffmpeg|A=mp3) [transcode] V: import frame | 480x320 1.50:1 [transcode] V: clip frame (<-) | 480x192 [transcode] V: zoom | 800x368 1.30:1 ( Lanczos3) [transcode] V: bits/pixel | 0.245 [transcode] V: decoding fps,frc | 25.000,3 [transcode] V: Y'CbCr | YV12/I420 [transcode] A: import format | 0x55 MPEG laye r-3 [22050,16,2] 96 kbps [transcode] A: export format | 0x55 MPEG laye r-3 [22050,16,2] 128 kbps [transcode] V: encoding fps,frc | 25.000,3 [transcode] A: bytes per frame | 3528 (3528.000000 ) [transcode] A: adjustment | 0@1000 [transcode] V: IA32/AMD64 accel | sse2 (sse2 sse mm xext mmx asm C) [transcode] V: IA32/AMD64 accel | using sse2 memcpy [transcode] V: video buffer | 10 @ 800x368 [import_mp3.so] v0.1.4 (2003-08-04) (audio) MPEG [import_ffmpeg.so] v0.1.13 (2007-10-09) (video) ffm peg: MS MPEG4v1-3/MPEG4/MJPEG [export_xvid4.so] v0.0.6 (2007-08-11) (video) XviD 1.0.x series (aka API 4.0) | (audio) MPEG/AC3/PCM [import_mp3.so] MP3->PCM [import_mp3.so] tcextract -a 0 -i "/Compartilhada/m ichael w smith and hillsong 2007.avi" -x mp3 -d 0 | tcdecode -x mp3 -d 0 -z 120 00 [export_xvid4.so] Neither './xvid4.cfg' nor '~/.tra nscode/xvid4.cfg' [export_xvid4.so] found. Default settings will be u sed instead. Audio: using new version Audio: using lame-3.98.2 [encoder.c] Delaying audio (0) [mpeg4 @ 0x37f3fcd410]overreading 9 bitsfps, EMT: 0 :00:30, ( 0| 0| 9) [mpeg4 @ 0x37f3fcd410]concealing 600 DC, 600 AC, 60 0 MV errors encoding frames [000000-082479], 23.61 fps, EMT: 0 :54:59, ( 0| 0| 4) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 82480 frames (0 dropped, 0 clon ed), clip length 3299.20 s Seg Nov 17 00:45:54 BRST 2008 [root@Dom01 Compartilhada]#

78

ANEXO J: SAÍDA DE EXECUÇÃO DA CODIFICAÇÃO DE VIDEO NO VMWARE

[root@VMWARE timm]# date ; transcode -y xvid -j 6 4,0 -Z 800x368 -i /home/timm/michael\ w\ smith\ and\ hillsong\ 2007.a vi -o /home/timm/final.avi ; date Dom Nov 16 12:27:09 BRST 2008 transcode v1.0.5 (C) 2001-2003 Thomas Oestreich, 20 03-2004 T. Bitterberg, 2004-2008 Transcode Team [transcode] (probe) suggested AV correction -D 0 (0 ms) | AV 0 ms | 0 ms [transcode] auto-probing source /home/timm/michael w smith and hillsong 2007.avi (ok) [transcode] V: import format | DivX RIFF data, A VI (V=ffmpeg|A=mp3) [transcode] V: import frame | 480x320 1.50:1 [transcode] V: clip frame (<-) | 480x192 [transcode] V: zoom | 800x368 1.30:1 ( Lanczos3) [transcode] V: bits/pixel | 0.245 [transcode] V: decoding fps,frc | 25.000,3 [transcode] V: Y'CbCr | YV12/I420 [transcode] A: import format | 0x55 MPEG laye r-3 [22050,16,2] 96 kbps [transcode] A: export format | 0x55 MPEG laye r-3 [22050,16,2] 128 kbps [transcode] V: encoding fps,frc | 25.000,3 [transcode] A: bytes per frame | 3528 (3528.000000 ) [transcode] A: adjustment | 0@1000 [transcode] V: IA32/AMD64 accel | sse2 (sse2 sse mm xext mmx asm C) [transcode] V: IA32/AMD64 accel | using sse2 memcpy [transcode] V: video buffer | 10 @ 800x368 [import_mp3.so] v0.1.4 (2003-08-04) (audio) MPEG [import_ffmpeg.so] v0.1.13 (2007-10-09) (video) ffm peg: MS MPEG4v1-3/MPEG4/MJPEG [export_xvid4.so] v0.0.6 (2007-08-11) (video) XviD 1.0.x series (aka API 4.0) | (audio) MPEG/AC3/PCM [import_mp3.so] MP3->PCM [import_mp3.so] tcextract -a 0 -i "/home/timm/micha el w smith and hillsong 2007.avi" -x mp3 -d 0 | tcdecode -x mp3 -d 0 -z 120 00 [export_xvid4.so] Neither './xvid4.cfg' nor '~/.tra nscode/xvid4.cfg' [export_xvid4.so] found. Default settings will be u sed instead. Audio: using new version Audio: using lame-3.98.2 [encoder.c] Delaying audio (0) [mpeg4 @ 0x36979cd410]overreading 9 bitsfps, EMT: 0 :00:30, ( 0| 0| 9) [mpeg4 @ 0x36979cd410]concealing 600 DC, 600 AC, 60 0 MV errors encoding frames [000000-082479], 21.42 fps, EMT: 0 :54:59, ( 0| 0| 4) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 82480 frames (0 dropped, 0 clon ed), clip length 3299.20 s Dom Nov 16 13:31:20 BRST 2008 [root@VMWARE timm]#

79

ANEXO K: SAÍDA DE EXECUÇÃO DO AB NO KVM

[root@lima ~]# ab -n 200000 -c 100 http://192.168.1 .3/ This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, htt p://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http ://www.apache.org/ Benchmarking 192.168.1.3 (be patient) Completed 20000 requests Completed 40000 requests Completed 60000 requests Completed 80000 requests Completed 100000 requests Completed 120000 requests Completed 140000 requests Completed 160000 requests Completed 180000 requests Finished 200000 requests Server Software: Apache/2.2.3 Server Hostname: 192.168.1.3 Server Port: 80 Document Path: / Document Length: 5043 bytes Concurrency Level: 100 Time taken for tests: 253.772404 seconds Complete requests: 200000 Failed requests: 0 Write errors: 0 Non-2xx responses: 200001 Total transferred: 1048005240 bytes HTML transferred: 1008605043 bytes Requests per second: 788.11 [#/sec] (mean) Time per request: 126.886 [ms] (mean) Time per request: 1.269 [ms] (mean, across al l concurrent requests) Transfer rate: 4032.91 [Kbytes/sec] receiv ed Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 35.5 0 3001 Processing: 15 125 138.6 123 20016 Waiting: 14 124 110.3 122 20014 Total: 18 126 143.0 123 20016 Percentage of the requests served within a certain time (ms) 50% 123 66% 124 75% 125 80% 126 90% 131 95% 135 98% 160 99% 167 100% 20016 (longest request) [root@lima ~]# ab -n 200000 -c 200 http://192.168.1 .3/

80

This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, htt p://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http ://www.apache.org/ Benchmarking 192.168.1.3 (be patient) Completed 20000 requests Completed 40000 requests Completed 60000 requests Completed 80000 requests Completed 100000 requests Completed 120000 requests Completed 140000 requests Completed 160000 requests Completed 180000 requests Finished 200000 requests Server Software: Apache/2.2.3 Server Hostname: 192.168.1.3 Server Port: 80 Document Path: / Document Length: 5043 bytes Concurrency Level: 200 Time taken for tests: 255.577280 seconds Complete requests: 200000 Failed requests: 0 Write errors: 0 Non-2xx responses: 200000 Total transferred: 1048000000 bytes HTML transferred: 1008600000 bytes Requests per second: 782.54 [#/sec] (mean) Time per request: 255.577 [ms] (mean) Time per request: 1.278 [ms] (mean, across al l concurrent requests) Transfer rate: 4004.41 [Kbytes/sec] receiv ed Connection Times (ms) min mean[+/-sd] median max Connect: 0 78 1085.1 0 93000 Processing: 1 175 366.8 161 63855 Waiting: 1 173 337.3 160 63854 Total: 22 253 1173.1 161 105917 Percentage of the requests served within a certain time (ms) 50% 161 66% 163 75% 168 80% 171 90% 176 95% 200 98% 406 99% 3162 100% 105917 (longest request) [root@lima ~]#

81

ANEXO L: SAÍDA DE EXECUÇÃO DO AB NO XEN

[root@lima ~]# ab -n 200000 -c 100 http://192.168.1 .9/ This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, htt p://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http ://www.apache.org/ Benchmarking 192.168.1.9 (be patient) Completed 20000 requests Completed 40000 requests Completed 60000 requests Completed 80000 requests Completed 100000 requests Completed 120000 requests Completed 140000 requests Completed 160000 requests Completed 180000 requests Finished 200000 requests Server Software: Apache/2.2.3 Server Hostname: 192.168.1.9 Server Port: 80 Document Path: / Document Length: 5043 bytes Concurrency Level: 100 Time taken for tests: 140.361135 seconds Complete requests: 200000 Failed requests: 0 Write errors: 0 Non-2xx responses: 200000 Total transferred: 1048000000 bytes HTML transferred: 1008600000 bytes Requests per second: 1424.90 [#/sec] (mean) Time per request: 70.181 [ms] (mean) Time per request: 0.702 [ms] (mean, across al l concurrent requests) Transfer rate: 7291.46 [Kbytes/sec] receiv ed Connection Times (ms) min mean[+/-sd] median max Connect: 0 40 303.1 13 9017 Processing: 1 29 31.1 23 697 Waiting: 0 28 31.0 23 696 Total: 2 69 304.9 39 9042 Percentage of the requests served within a certain time (ms) 50% 39 66% 45 75% 48 80% 51 90% 59 95% 69 98% 244 99% 290 100% 9042 (longest request) [root@lima ~]# ab -n 200000 -c 200 http://192.168.1 .9/

82

This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, htt p://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http ://www.apache.org/ Benchmarking 192.168.1.9 (be patient) Completed 20000 requests Completed 40000 requests Completed 60000 requests Completed 80000 requests Completed 100000 requests Completed 120000 requests Completed 140000 requests Completed 160000 requests Completed 180000 requests Finished 200000 requests Server Software: Apache/2.2.3 Server Hostname: 192.168.1.9 Server Port: 80 Document Path: / Document Length: 5043 bytes Concurrency Level: 200 Time taken for tests: 132.882846 seconds Complete requests: 200000 Failed requests: 0 Write errors: 0 Non-2xx responses: 200000 Total transferred: 1048000000 bytes HTML transferred: 1008600000 bytes Requests per second: 1505.09 [#/sec] (mean) Time per request: 132.883 [ms] (mean) Time per request: 0.664 [ms] (mean, across al l concurrent requests) Transfer rate: 7701.80 [Kbytes/sec] receiv ed Connection Times (ms) min mean[+/-sd] median max Connect: 0 74 396.6 34 21007 Processing: 1 56 61.5 46 3325 Waiting: 0 55 61.3 45 3324 Total: 5 131 400.8 84 21054 Percentage of the requests served within a certain time (ms) 50% 84 66% 91 75% 95 80% 98 90% 110 95% 129 98% 330 99% 3069 100% 21054 (longest request) [root@lima ~]#

83

ANEXO M: SAÍDA DE EXECUÇÃO DO AB NO VMWARE SERVER

[root@lima ~]# ab -n 200000 -c 100 http://192.168.1 .7/ This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, htt p://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http ://www.apache.org/ Benchmarking 192.168.1.7 (be patient) Completed 20000 requests Completed 40000 requests Completed 60000 requests Completed 80000 requests Completed 100000 requests Completed 120000 requests Completed 140000 requests Completed 160000 requests Completed 180000 requests Finished 200000 requests Server Software: Apache/2.2.3 Server Hostname: 192.168.1.7 Server Port: 80 Document Path: / Document Length: 5043 bytes Concurrency Level: 100 Time taken for tests: 181.613557 seconds Complete requests: 200000 Failed requests: 0 Write errors: 0 Non-2xx responses: 200000 Total transferred: 1048000000 bytes HTML transferred: 1008600000 bytes Requests per second: 1101.24 [#/sec] (mean) Time per request: 90.807 [ms] (mean) Time per request: 0.908 [ms] (mean, across al l concurrent requests) Transfer rate: 5635.25 [Kbytes/sec] receiv ed Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 32.2 0 3001 Processing: 47 89 173.9 87 31726 Waiting: 47 88 162.3 86 31723 Total: 50 90 176.8 87 31726 Percentage of the requests served within a certain time (ms) 50% 87 66% 89 75% 91 80% 93 90% 100 95% 112 98% 129 99% 141 100% 31726 (longest request) [root@lima ~]#

84

[root@lima ~]# ab -n 200000 -c 200 http://192.168.1 .7/ This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 Copyright 1996 Adam Twiss, Zeus Technology Ltd, htt p://www.zeustech.net/ Copyright 2006 The Apache Software Foundation, http ://www.apache.org/ Benchmarking 192.168.1.7 (be patient) Completed 20000 requests Completed 40000 requests Completed 60000 requests Completed 80000 requests Completed 100000 requests Completed 120000 requests Completed 140000 requests Completed 160000 requests Completed 180000 requests Finished 200000 requests Server Software: Apache/2.2.3 Server Hostname: 192.168.1.7 Server Port: 80 Document Path: / Document Length: 5043 bytes Concurrency Level: 200 Time taken for tests: 181.529958 seconds Complete requests: 200000 Failed requests: 0 Write errors: 0 Non-2xx responses: 200000 Total transferred: 1048000000 bytes HTML transferred: 1008600000 bytes Requests per second: 1101.75 [#/sec] (mean) Time per request: 181.530 [ms] (mean) Time per request: 0.908 [ms] (mean, across al l concurrent requests) Transfer rate: 5637.84 [Kbytes/sec] receiv ed Connection Times (ms) min mean[+/-sd] median max Connect: 0 54 593.1 0 45001 Processing: 1 125 258.8 117 37988 Waiting: 0 124 237.1 116 33269 Total: 35 179 648.9 117 45176 Percentage of the requests served within a certain time (ms) 50% 117 66% 120 75% 123 80% 125 90% 136 95% 158 98% 321 99% 3115 100% 45176 (longest request) [root@lima ~]#

85

ANEXO N: SAÍDA DE EXECUÇÃO DAS CÓPIAS DE ARQUIVO PO R NFS

Saída texto do procedimento de transferência de arquivos a partir de um

host Linux na rede via NFS no VMware.

[root@lima home]# mount -t nfs 192.168.1.7:/Compart ilhada /mnt/nfs [root@lima home]# date ; cp /home/centos.iso /mnt/ nfs/ ; date Qui Nov 20 01:14:50 BRST 2008 Qui Nov 20 01:21:47 BRST 2008 [root@lima home]#


host Linux na rede via NFS no Xen.

[root@lima home]# mount -t nfs 192.168.1.9:/Compart ilhada /mnt/nfs [root@lima home]# date ; cp /home/centos.iso /mnt/ nfs/ ; date Qua Nov 19 00:40:23 BRST 2008 Qua Nov 19 00:49:37 BRST 2008 [root@lima home]#


host Linux na rede via NFS no KVM.

[root@lima home]# mount -t nfs 192.168.1.3:/Compart ilhada /mnt/nfs [root@lima home]# date; cp /home/centos.iso /mnt/n fs/ ; date Sex Nov 21 21:29:03 BRST 2008 Sex Nov 21 21:38:33 BRST 2008 [root@lima home]#

faculdade de tecnologia senai de desenvolvimento gerencial...

Documents