> Primeiro gostaria de parabenizar por este excelente iniciativa de
> criar uma comunidade XEN no Brasil, com excelente documentação - uma
> comunidade com Wiki, lista de discussão e com esta qualidade é muito
> rara.
O diferencial da comunidade SL/CA como um todo no Brasil é destaque
pela criatividade e qualidade.
> Bem, gostaria de propor aqui uma discussão sobre conceitos e jargões
> utilizados pelo XEN, principalmente aos iniciantes. Depois, quem sabe,
> poderá virar documentação no Xen-br.
Opa, muito interessante esta abordagem. Acho que de fato está faltando
algo neste sentido no wiki. Vamos construir algo semelhante à isso.
>
> 1. Pra começar gostaria que alguém podesse esclarecer qual a diferença
> de discos virtuais: xvda e sda.
Comumente sd[x] no linux se refere a "scsi disk + [a,b.c.x]" que são
dispositivos de bloco que utilizam protocolo o SCSI para acessar os
dados nos blocos (corrijam-me se eu estiver enganado) bem como hd[x]
no linux se referindo à "hard disk whatever".
Com a intenção de se identificar discos de uma maquina virtual Xen, o
nome xvd (Xen Virtual Disk) é utilizado para facilitar esta
identificação. Um XVD do xen só é identificado quando se utiliza a
paravirtualização do dispositivo de bloco.
> 2. Pra que diabos serve o pvgrub?
O pvgrub veio a substituir o pygrub por diversas questões relacionadas
principalmente à segurança. Ele utiliza o codigo original com alguns
patches do grub para prover acesso à mbr de um XVD, fazer a leitura
das tabelas de partições da mbr e acessar o sistema de arquivos para a
leitura do menu.lst e assim prover um promp interativo para boot do
sistema operacional paravirtualizado.
> 3. Eu só posso utilizar o pvscsi em máquinas HVM (Full virtualized)?
Não tive ainda possibilidade de utilizar o pvscsi mas até onde sei ele
pode ser utilizado tanto para HVM qto para PVM. Com pvscsi vc reserva
um dispositivo fisico SCSI real para a maquina virtual e ela detecta
como se fosse um SCSI BUS tb real.
Vamos discutindo estes assuntos e melhorando para podermos documentar isso.
Abraços!
--
Marco Sinhoreli
2008/10/3 Marco Sinhoreli <msin...@gmail.com>:
A intenção do pvscsi nao e inicialmente prover disco com comandos SCSI
para a domU
mas sim passar um SCSI bus para acesso a fitas , scanners e
dispositivos SCSI (menos disco)
valeu pela correção liberie!
[]s
2008/10/3 Liberie Cunha-Neto <lib...@gmail.com>:
--
Marco Sinhoreli
tap deve ser usado para file loop (colocando o domU dentro de um
arquivo) , so que claro vai ser um problema para sua performance ja
que tudo de disco o dom0 ira ter de fazer o loop para o arquivo
phy , e usado para devices a performance e bem melhor usando phy
2008/10/8 Henrique Bueno <henriq...@gmail.com>:
> cpu
designa quais cpu's fisicas será utilizada pela vm
# deixa o xen escolher
cpus = ""
# As VCPUs usarão a CPU0
cpus = "0"
# Todas as VCPUs usarão a CPU0 e CPU2
cpus = "0,2"
# Usará da CPU0 até CPU3 e CPU5
cpus = "0-3,5.^1"
# VCPU0 roda na CPU2 e VCPU1 roda na CPU5
cpus = [ "2", "5" ]
# Numero de CPUs virtuais que será apresentado no /proc/cpuinfo.
Suporte até 32 VCPUS mesmo
# que o hardware tenha menos CPUs:
vcpus = "32"
# '''cpu''' é ultrapassado e se utiliza agora '''cpu''' pois prove
funções dinamicas para alocação de CPUs.
> Eu posso gerenciar os processadores "a quente"? Tipo tirar de uma e passar
> para outra sem desligar as domUs
É possivel manipular isso. Alguns exemplos:
# xm vcpu-list 13
Name ID VCPU CPU State Time(s) CPU Affinity
pvmtest 13 0 0 -b- 1.7 any cpu
pvmtest 13 1 1 -b- 0.9 any cpu
pvmtest 13 2 1 -b- 0.9 any cpu
pvmtest 13 3 0 -b- 1.0 any cpu
No caso acima a vm pvmtest está utilizando qualquer CPU. A alocação é
dinamicamente feita pelo Xen.
Após os comandos abaixo:
# xm vcpu-pin 13 0 0
# xm vcpu-pin 13 1 1
# xm vcpu-pin 13 2 0
# xm vcpu-pin 13 3 1
# xm vcpu-list 13
Name ID VCPU CPU State Time(s) CPU Affinity
pvmtest 13 0 0 -b- 3.0 0
pvmtest 13 1 1 -b- 1.6 1
pvmtest 13 2 0 -b- 1.4 0
pvmtest 13 3 1 -b- 1.9 1
Alterei a VCPU0 para utilizar a CPU0 e não '''any''' como antes,
Alterei a VCPU1 para utilizar a CPU1 e não '''any''' como antes,
Alterei a VCPU2 para utilizar a CPU0 e não '''any''' como antes,
Alterei a VCPU3 para utilizar a CPU1 e não '''any''' como antes.
Isso sim é possivel manipular a '''quente'''.
Vc não mencionou mas vou abordar.
# scheduler-credit:
Utilizo Xen em meu desktop com pentium D. Quanto instancio vms windows
percebo que fica praticamente impossivel utilizar meu desktop que está
no dom0. O Xen prioriza a vm por razões obvias: Xen é pra ser
utilizado em servidores e não em desktops :-) Para dar prioridade ao
Dom0 que está rodando meu desktop, posso manipular as features de
prioridade do scheduler afim de conseguir pelo menos manipular meu
pobre mouse:
# xm sched-credit -d Domain-0 -w 1024
Consigo mover meu mouse! O scheduler default é 256 para todas as vms.
Este mesmo esquema pode ser utilizado em um setup de servidores
virtuais.
Outro lance legal do scheduler-credit é a possibilidade de se
manipular qual o maximo do timer das CPU que a vm pode utilizar:
# xm sched-credit -d pvmtest -c 150
Veja bem, tenho um processador com 2 core, então neste caso,
permitirei a utilização de 150% da soma de meus processadores. 1
processador equivale a 100% e dois, obvio, 200% :-)
Usage: xm sched-credit [-d <Domain> [-w[=WEIGHT]|-c[=CAP]]]
Get/set credit scheduler parameters.
-d DOMAIN, --domain=DOMAIN Domain to modify
-w WEIGHT, --weight=WEIGHT Weight (int)
-c CAP, --cap=CAP Cap (int)
--
Marco Sinhoreli
'''cpu''' é ultrapassado e se utiliza agora '''cpus''' pois prove
funções dinamicas para alocação de CPUs.
--
Marco Sinhoreli