Estou enviando o material com capítulo 2, cujo tema é "Introdução ao
Xen" e o capítulo 1 que ganhou mais uma seção. No novo capítulo, o
principal objetivo é mostrar a arquitetura do Xen (Hypervisor,
domain-0, xend, xenstore, etc) sem entrar em detalhes de configuração.
A partir do capítulo 3 o material passa a ser mais prático (exceto o
capítulo 5) contendo procedimentos de instalação, configurações,
etc...
Meu cronograma esta assim:
- até 24/10: Capítulo 3: Xen Hypervisor
- até 31/10: Capítulo 4: Xend
- até 07/11: Capítulo 5: Xenstored/XenBus/Xenconsole
- até 14/11: Capítulo 6: Guests (área de disco, instalação, definição
de recursos)
- até 21/11: Capítulo 7: Xm
- até 28/11: Capítulo 8: Xen-API
- 2010: desenvolver uma interface para o Xen (idéia semelhante ao
Korreio), ainda estou pensando em um nome. :)
[]s
--
Reinaldo de Carvalho
http://korreio.sf.net
http://python-cyrus.sf.net
"Don't try to adapt the software to the way you work, but rather
yourself to the way the software works" (myself)
Olá Marco,
> entendo que vc tb esteja aberto à receber possíveis criticas,
Esse é o objetivo. No meu primeiro email eu comentei: "o material
retrata o meu ponto de vista, não quer dizer que tudo esteja certo".
> correções e sugestões sobre a sua publicação. Como
> membro do grupo e tb considerando que em seu livro com certeza o
> xen-br deverá ser citado até mesmo pela ajuda que as pessoas aqui na
> lista tem se empenhado, gostaria de sugerir algumas correções de
> aspecto semantico
Estou aguardando estas sugestões/correções.
> em seu texto relativo ao 1.1.1 onde vc cita que a
> "Alta performace" está relacionada à copia da paginação de memória de
> um guest.
A "alta performace" é referente a capacidade de se obter mais
processamento quando for necessário. Se um Guest esta requerendo mais
poder de processamento que a máquina atual, você pode migrá-lo para
outra máquina e garantir a performace que ele precisa. Assim você pode
garantir alta performace, seja manualmente ou altomaticamente
desenvolvendo um programa que analise o uso das CPUs reais, e migre
o(s) Guest(s) que estão exigindo mais processamento, podendo inclusive
ligar outra máquina física através de wake-on-lan.
Esse programação de migração automática é tranquilamente
implementável, e o resulta será sempre "alta performace". Entendeu meu
ponto de vista?
> Discordo de vc neste aspecto pois não tem relacionamento
> entre "alta perfornace" e "live-migration" já que neste aspecto não
> existe mecanismos ligados à performace e sim ao metodo de copia
> inteligente pela rede das paginas da memoria e ao baixo downtime do
> sistema operacional virtualizado.
>
Agradeço sua colocação e vou refletir um tempo sobre isso, de repente
posso encontrar um termo melhor.
> Se vc não se incomodar, irei continuar a ler os capitulos subsequentes
> para posiciona-lo sobre estes aspectos sempre com um olhar critico e
> aprofundado sobre o tema que vc se propos à escrever. Temos aqui no
> grupo pessoas com conhecimentos avançados sobre virtualização e acho
> que para vc seria uma excelente parceria para publicar um material de
> alto nivel como vc se propos no seu primeiro post aqui na lista.
>
> Acredito que vc tb irá em sua publicação informar o auxilio do grupo
> de usuários e por este motivo me disponibilizarei a auxilia-lo quando
> possivel.
>
[]s