Windows 10 congela durante pré instalação / Windows 10 freezing during windows install (preinstall)

Apesar de não trocar o Windows 10 por nada (até aparecer coisa melhor, kkk), tem coisa que parece que a Microsoft gosta de deixar a vida mais díficil.

A long, long time ago… eu queria instalar a última build do Windows 10, que na época era 1803, pois eu estava utilizando o build 1709 muito feliz da vida, contudo, ao finalizar o update e após o restart, o Windows fica eternamente na tela de load, não parecia que havia congelado, mas ele ficava só naquilo… dava para ver algumas atividades aleatórias da HD, mas só ficava assim…

Depois de muito esforço para reverter o update, já que o próprio rollback não estava resolvendo — mais precisamente voltei meu full backup (felizmente adquiri o hábito de fazer um full antes de qualquer atualização mais crítica) — comecei a fazer diversas pesquisas mas o update era muito recente, até encontrei alguns reportando problema, acabei desistindo e fiquei com o meu bom e velho build 1709. Infelizmente era atormentado constantemente com as tentativas do Windows de se atualizar, mas suportável e relativamente simples de contornar isso, só ficava incomodado com os alertas de falta de atualização do Defender (Obrigado Microsoft pelo ótimo antivírus, deveria ter oferecido desde o WIN98).

Com o passar do tempo, surgiu o build 1903, e como já havia completamente esquecido todo o sofrimento de instalar o 1803, fiz meu full backup e depois de 2 horas, estava todo animado para ver as incríveis “poucas” novidades do 1903 e quando fez o restart para finalizar o update… BUUUMM…. o Windows 10 ficou no eterno congelamento… nessa hora, eu que fiquei congelado, por havia lembrado de todo o trampo do 1803. Depois de xingar toda a equipe de devel da MS. Até tentei fazer o rollback, que evidentemente não funcionou e claramente eu já estava preparado para o restore do full backup…

Depois de ter passado todo o tempo do restore, fiz diversas pesquisas e encontrei muita reclamação, o mesmo comportamento de ficar congelado, encontrei diversas sugestões, mas nada que fazia muito sentido… até mesmo tentei fazer uma instalação limpa em uma HD zerada… mas a mema coisa, atémesmo achei que poderia ser uma incompatibilidade com PCs mais antigos, apesar do meu PC ser uma baita máquina, já era bem antigo… e depois de muita pesquisa, acabei desistindo. E claro… infelizmente era atormentado — de novo — constantemente com as tentativas do Windows de se atualizar…

Recentemente, precisamente hoje dia 19-09-2020, resolvi que iria resolver esse problema, apesar de ser um baita trampo, eu queria porque queria fazer uma instalação limpa, então aceitei o risco de perder um sábado inteiro tentando resolver isso. Nessa data já havia sido disponibilizado o build 2004.

Comecei a abrir pelo menos 20 guias do navegador com diversos comentários e/ou dicas de como resolver, mas nada parecia fazer muito sentido, exceto alguns parâmetros da BIOS, mas estava relutante com essa ideia, já que o 1709 funciona então não achei que poderia ser BIOS, mass ok… eu iria tentar tudo… MENOS tirar os pentes de memória, já que vi dica sugerindo testar com 1 único pente de memória ( OMG ). Mas na epoca do 1803, cheguei a testar com 1 pente =/

Então vamos lá com as dicas que NÃO funcionaram, nem no 1803 e muito menos 1903 e 2004…

Desisti de fazer a lista com as dicas que NÃO funcionaram… hauuauahua… porque qualquer pesquisa que alguem for fazer vai aparecer as mais diversas dicas, incluindo trocar de máquina…

Então vamos lá para a solução:

1. Salvei meu atual settings da BIOS em um profile, já que ela permite salvar diversos profiles.
2. Resetei a BIOS para os valores default (snifff…).
3. Como o install do WIN10 “não parecia” estar congelado, resolvi testar o 2004 com uma outra placa de vídeo (VC). Eu tinha uma otima placa de vídeo que estava parada, que alias é muito muito mais power que atual… mas tinha tirado porque eu estava achando que ela travava o meu computador, mas ok… o foco era resolver o build 2004, entao troquei de placa de vídeo.
4. Durante as pesquisas, indiretamente achei um artigo que a MS não estava mais desenvolvendo o WIN10 e testando em harware físico mas tudo em VM. Se isso era uma verdade, eu não sei… mas faz muito sentido, pois eu mesmo desenvolvo e testo muita coisa em VM… entao comecei a suspeitar que poderia de alguma for ser BIOS.
5. Com essa ideia da BIOS, algo ficava no meu ouvido dizendo… MODO RAID… MODO RAID… MODO RAID… e como eu minhas HDs estao em RAID-10, senti uma dor no peito, achando que eu iria infartar, só de pensar em quebrar a RAID, então, peguei uma HD nova e alterei o modo RAID para modo AHCI e só deixei uma HD zerada…
6. Baixie o latest MediaCreationTool2004 e criei o instalador do WIN10 em um pendrive (odeio cd/dvd).
7. Ao executar o instalador, após alguns minutos….BUUUMMMM… apareceu o wizard (ou será WINzard?!) da instalação…. GLORIA A DEUSSSHHHH.
8. Restaurei o valores da minha BIOS para os valores personalizados, mas deixando o modo AHCI ativado, e executei novamente o instalador mas dessa vez não deu certo.
9. Resetei novamente a BIOS para os valores default, modo AHCI ativado, AI. OVERCLOCK TUNER para X.M.P, e só… restart e … BUUMMM… DEU CERTO!!!

Conclusão: Não acho que seja a placa de vídeo (VC), mas com certeza algum parametro da BIOS, mas com total certeza o modo AHCI ativado. Entre as pesquisar já sugeriam desabilitar o Legacy Floppy Drive Support e também desabilitar o Intel SpeedStep, mas desde sempre já ficavam desabilitados.

UPDATE: 20/09

>>>De fato, o problema esta no Intel VT–d (Virtualização Trusted I/O), ou seja, para funcionar o install do WIN10 com build 2004, requer VT–d desativado, porem funciona tanto o modo AHCI quanto o modo RAID.

Pedido à Microsoft:

Querida Microsoft, por favor no próximo natal implemente um modo verbose durante install do Windows, não através do arquivo de log que já tem (que aliás é horrível), mas um log que apareça em realtime na tela, até mesmo o MACOS tem um verbose realtime.

Algumas Referências: (lamento, esqueci de anotar todas as pesquisar, incluindo o artigo que menciona o desenvolvimento do WIN10 em VMs)

https://answers.microsoft.com/en-us/windows/forum/all/cpu-bios-setting-for-win-10-compatibility/511e97b9-a635-402a-9dad-8d1f3a6862ea

https://answers.microsoft.com/en-us/windows/forum/all/bios-incompatibilty-with-windows-10-64bit-desktop/6bdd31b3-e916-49c9-afc0-03e8b5fa1764

https://answers.microsoft.com/en-us/windows/forum/all/windows-10-and-bios-settings-help/ad0ae404-a034-4c1a-a384-5b8ab130dcc7

https://www.bleepingcomputer.com/forums/t/702613/new-pc-freezing-during-windows-install/

https://forums.tomshardware.com/threads/new-pc-windows-10-installation-freezes-on-blue-logo-screen.3431719/

https://answers.microsoft.com/en-us/windows/forum/all/new-build-pc-windows-10-freezes-on-install/84cd0b77-3b15-4dcd-8600-8750338d3a5a

https://social.technet.microsoft.com/Forums/en-US/4860cb9b-fd9c-4333-b7c1-3dce8e423a8c/windows-installation-keeps-freezing?forum=win10itprosetup

https://answers.microsoft.com/en-us/windows/forum/all/pc-freezes-when-trying-to-install-windows-10/23bf7f0a-f23d-4af4-8ae0-521b53a3943a

BitLocker Could Not Be Enabled: 5 Ways to Fix This Error

https://answers.microsoft.com/en-us/windows/forum/all/windows-10-freezing-upon-install-fresh-build-with/aafacfce-441e-4b97-92dd-d179ff6c56b9

https://answers.microsoft.com/en-us/windows/forum/windows_10-update/latest-windows-10-update-causes-pc-to-freeze-at/e7cb7791-16ab-45a3-825b-9cfc8ff3a37d

https://docs.microsoft.com/pt-br/windows/release-information/

Servidor IBM x3400 e o maquiavélico erro 0x0000007B

Olá sobreviventes…

Como sinto falta de postar os acontecimentos de campo, realmente tenho bastante coisa para postar, mas realmente ficaram bastante corridos esses meses, e peço desculpas para aqueles que estão esperando a continuação do post sobre Exchange e Smartphones, assim que eu organizar melhor essas mudanças na minha vida irá dedicar um pouco mais ao blog.

BTW, nesse último sábado, estive em um cliente que queria formatar um servidor IBM x3400 e instalar novamente o Windows Server 2003 R2. Esse servidor possui o SQL Server 2005 e uma database de 30GB. O desejo de reinstalar tudo é devido esse servidor ter sofrido seriamente diversos ataques de vírus, entre eles o Sality e Conflicker, o SQL estava “tão zuado” que o agente de jobs não conseguia executar nenhuma tarefa, como por exemplo backup além do que diversas consoles MMC estavam corrompidas, além de uma lentidão fora do normal.

A operação foi sem segredo, reiniciamos o servidor utilizando um WINPE e copiamos as databases utilizando o ROBOCOPY (adoro o nome de tool!) para uma HD externa. No meu notebook, um Samsung R480 com 6GB de RAM, havia previamente preparado uma VM com o mesmo Windows e com o SQL e também respeitando os mesmos updates que estavam instalados no servidor original. Realizamos um teste com as databases online e utilizamos o Totvs Protheus para confirmar que as databases estavam devidamente online e disponíveis para os users.

Como esse servidor possui uma controladora ServeRAID 8k, além dos motivos obvieis, utilizei o IBM SERVERGUIDE para preparar o servidor para a instalação automatizada do Windows Server 2003 R2. Para aqueles que não conhecem, o SERVERGUIDE é uma ferramenta de deploy que, entre outras vantagens, permite instalar uma versão do Windows que não possui os device drivers necessários, como nesse caso, o Windows Server 2003 R2 não possui em sua mídia original os devices drivers necessários para acessar o volume fornecido pela controladora ServeRAID.

Evidentemente utilizei a versão mais recente do SERVERGUIDE. Até a data da publicação desse post, a versão mais recente era 9.00. Como o SERVERGUIDE usa uma base do Windows Server 2008, foi fácil preparar um flash-disk e colocar os arquivos para ser “bootado” pelo próprio flash-disk, pois não tem coisa mais chata e lenta que usar uma mídia ótica para isso.

Iniciado com sucesso o SERVERGUIDE, o mesmo reconheceu o servidor, os discos e volume em RAID-5 corretamente. Depois de preenchido com as informações do wizard, foi iniciado automaticamente o executável do WINNT32 pelo próprio SERVERGUIDE copiando os arquivos de instalação para o volume. Tudo lindo e maravilhoso até a hora que foi realizada o reboot (não uso mais a palavra restart, por causa de uma suposta banda de gênero questionável). Ao ser iniciado a tela de SETUP com a carga dos device drivers de controladoras, o mesmo travou e foi exibido um BSD (blue screen of death). O erro apresentado era:

*** STOP: 0x0000007B (0x789EA94, 0x00000034, 0x00000000, 0x00000000)

Inicialmente a minha suspeita era memória, pois já tive alguns casos de com esse erro que, ao tirar algum pente de memória, o mesmo se comportava corretamente. Para confirmar se poderia ser memória, iniciei a execução do SETUP da própria mídia do Windows Server, e ao finalizar a carga dos devices drivers de controladoras, o mesmo conseguiu passar do ponto de erro, precisamente a tela já estava na opção de iniciar a instalação propriamente dita, claro que não reconheceu o volume pois o mesmo não possui o device driver apropriado. A solução era simples, apesar de todo o tempo perdido para essa conclusão: Utilizar uma versão mais antiga do SERVERGUIDE, precisamente a versão utilizada com sucesso foi a 8.41.

Fica a dica: Ao utilizar algum hardware relativamente antigo e um software também antigo, como por exemplo, o próprio Windows Server 2003, em muitos casos, o device driver mais atual pode ser o causador do problema.

Abraços e até a próxima!

Lição do Dia

Nunca deixe um usuário fazer o trabalho de um analista de suporte.

O que é Virtualização? – Parte 3

Continuando com o artigo sobre o que é virtualização, hoje apresento alguns detalhes técnicos sobre as diferentes tecnologias de virtualização.

As Tecnologias de Virtualização

 

Introdução a Virtualização

Ao longo dos últimos anos, muitas organizações se voltaram para a tecnologia de virtualização para consolidar servidores físicos e reverter a tendência de expansão de servidores, bem como menor consumo elétrico, refrigeração e os custos de espaço para lidar com orçamentos cada vez menores. Recentemente, as tecnologias de virtualização de aplicativos e desktops também surgiram e foram adoptadas em um esforço para simplificar a implementação e gestão das infraestruturas do usuário final.

Cada vez mais, departamentos de Tecnologia da Informação (TI) descobrem que virtualização de infraestruturas proporcionam ambientes mais flexíveis para operar e contribuir para mais rapidamente se adaptar às constantes mudanças empresariais.

Virtualização, no contexto de software, como por exemplo, o Microsoft Hyper-V Server e Virtual Server 2005 R2, pode ser descrito como a abstração de recursos físicos do sistema de modo que várias partições lógicas possam serem criadas para hospedar um conjunto heterogêneo de sistemas operacionais, cada um executando simultaneamente em um único servidor físico.

Cada partição lógica, também conhecida como Máquina Virtual (VM – Virtual Machine) é um ambiente de software que apresenta recursos (através de emulação de hardware ou outros dispositivos), no topo do qual um sistema operacional e um ou mais aplicativos podem ser instalados e executados.

Embora a virtualização tornou-se intensivamente adotada em ambientes de TI baseados em x86 somente na década atual, a tecnologia em si foi realmente introduzida pela primeira vez há 40 anos.

 

Virtualização baseada em x86

Na última década, as pesquisas de tecnologia de virtualização e o desenvolvimento de produtos têm estado focado na plataforma x86 (32 bits e 64 bits). Em 2006, a AMD e Intel liberaram revisões de processadores x86 com novas instruções e extensões especificamente dirigidas para habilitar a virtualização auxiliada por hardware.

As deficiências da plataforma legada de processadores x86 em relação aos recursos atuais de virtualização não impediu os fornecedores de software de desenvolver soluções antes do lançamento do Intel Virtualization Technology (Intel VT) e AMD-Virtualization (AMD-V). Na verdade, vários tipos de tecnologias de virtualização foram criados para serem executados na arquitetura original do processador x86, utilizando diversas metodologias que diferem em seu nível de abstração, limitações e problemas.

 

O que é Virtualização de Software?

Virtualização de software inclui várias técnicas para permitir que um único sistema físico hospede várias partições isoladas e seguras entre elas, compartilhando simultaneamente recursos do sistema físico. Essas abordagens diferentes variam em densidade de partição (o número de partições simultâneas), escalabilidade, desempenho e abrangência de sistemas operacionais que podem ser suportadas simultaneamente em uma determinada plataforma.

 

Virtualização em nível de Máquina

A base de uma solução de virtualização de nível de máquina é o Monitor de Máquina Virtual (Virtual Machine Monitor – VMM). O VMM é responsável pela criação, isolamento e preservação do estado da máquina virtual, bem como a orquestração de acesso aos recursos do sistema. O VMM está vinculado a uma arquitetura de processador específico. Embora permita que diferentes sistemas operacionais possam executar em máquinas virtuais, contudo está limitado a sistemas operacionais que possam ser executados nativamente no processador físico do sistema.

Na figura abaixo ilustra três diferentes implementações de VMM: Tipo-2, o modelo “híbrido”, e Tipo-1. O VMM de tipo-2 é executado sobre um sistema operacional hospedeiro (host), como o Java VM. No modelo “híbrido”, o VMM é executado como um par (peer) para o sistema operacional host. Essa tipo de implementação é utilizada, por exemplo, no software Microsoft Virtual Server 2005 R2. Em contraste, um VMM de tipo-1, ou “hypervisor”, é executado diretamente no hardware abaixo de todas as partições da máquina virtual. O software Microsoft Hyper-V é uma solução baseada em hypervisor.

Em termos de desempenho, o hypervisor (VMM de tipo-1) é geralmente capaz de atingir níveis mais elevados de eficiência e, portanto, maior densidade de máquina virtual. Os outros tipos de VMMs dependem do sistema operacional host para o acesso aos recursos, o que resulta em mudanças de contexto mais custoso, menor desempenho e de maior sobrecarga ao sistema.

Apesar das diferentes implementações de VMM, as três variantes principais são usadas para criar uma interface entre as máquinas virtuais e os recursos do sistema virtualizado. Esses métodos são denominados Virtualização Completa (Full Virtualization), a Virtualização Nativa (Native Virtualization) e Paravirtualização (Paravirtualization).

 

Virtualização Completa

Nesse método, um sistema virtual completo é criado e mantido pelo VMM para abstrair o hardware real da máquina virtual. Esse método permite que um sistema operacional seja executado em uma máquina virtual sem qualquer modificação. O software Virtual Server 2005 R2 usa essa técnica junto com tradução binária, um processo que permite ao VMM tratar com instruções x86 não-virtualizáveis para fornecer virtualização em processadores x86 anteriores ao Intel VT e AMD-V.

Uma vantagem da virtualização completa e abordagem de dissociação entre o hardware físico da máquina virtual é a capacidade de mover máquinas virtuais facilmente entre servidores com configurações físicas diferentes, contudo essa flexibilidade vem com um impacto no desempenho por causa da sobrecarga associada com a manutenção de cada estado da máquina virtual e da latência introduzida com a tradução binária.

 

Virtualização Nativa

Virtualização nativa depende de uma arquitetura de processador virtualizável, como por exemples os processadores AMD-V e Intel VT. Esses processadores implementam novos modos de execução, instruções e construções de dados em hardware que são projetados para reduzir a complexidade do VMM.

Com a virtualização nativa, o VMM não é mais necessita manter o estado e as características de recursos da máquina virtual em software; essas funções agora pertencem ao hardware do processador. Assim como no caso da virtualização completa, sistemas operacionais podem rodar sem modificações dentro de máquinas virtuais. Hyper-V utiliza esse método para executar sistemas operacionais legados.

Este tipo de implementação tem muitas vantagens potenciais, que vão desde a simplificação da arquitetura do VMM para oferecer melhorias de desempenho significativas bem como a redução de sobrecarga baseada em software. Ao reduzir a sobrecarga da virtualização, uma maior densidade de partição pode ser alcançada em qualquer sistema.

 

Paravirtualização

Paravirtualização foi desenvolvido como uma alternativa ao uso de tradução binária para lidar com instruções x86 não-virtualizáveis. Nesse método os sistemas operacionais convidados (guests) requerem modificação para permitir “hiperchamadas” da máquina virtual para o hypervisor. Em vez de ter o hypervisor (ou VMM) traduzir uma instrução potencialmente perigosa do sistema operacional convidado, uma “hiperchamada” estruturada é feita a partir do convidado para o hypervisor para gerenciar as mudanças de estado do sistema. Nesse modelo o sistema operacional é modificado para chamar o VMM sempre que executar uma instrução que possa alterar o estado do sistema, uma instrução sensível. Isso acaba com a necessidade do VMM testar instrução por instrução, o que representa um ganho significativo de desempenho. Outro ponto positivo da paravirtualização é que os dispositivos de hardware são acessados por drivers da própria máquina virtual, não necessitando mais do uso de drivers genéricos que inibiam o uso da capacidade total do dispositivo.

Embora a paravirtualização apresentasse um ganho de desempenho significativo frente à virtualização completa, essa disparidade tem sido superada devido à presença de instruções de virtualização nos processadores Intel VT e AMD-V.

A paravirtualização foi lançada e implementada pela XenSource (recentemente adquirida pela Citrix), que produziu a solução de virtualização Xen de código aberto. Os lançamentos iniciais de Xen suportavam apenas alguns sistemas operacionais modificados. Com o lançamento do Xen 3.0, que alavancou a funcionalidade de virtualização de hardware da AMD-V e Intel VT, um sistema operacional Windows XP inalterado podia ser executado em uma máquina virtual convidada.

 

Virtualização em nível de Sistema Operacional

Virtualização em nível de sistema operacional é baseada na abstração da camada do sistema operacional para suportar múltiplas partições isoladas ou para suportar ambientes virtuais (VEs) em uma instância única do sistema operacional do host. A virtualização é realizada através do acesso de multiplexação ao kernel, enquanto que assegura que nenhum único VE seja capaz de derrubar o sistema.

Esta técnica resulta em baixa sobrecarga de virtualização e pode render alta densidade de partição. No entanto, existem dois grandes inconvenientes com este tipo de solução. A primeira desvantagem é a incapacidade de executar uma mistura heterogênea de sistema operacional em um determinado servidor, porque todas as partições compartilham um único kernel do sistema operacional. A segunda desvantagem, também causada pelo modelo de kernel compartilhado, é a falta de suporte à execução de carga de trabalho mista de 32-bit e 64-bit.

Parallels Virtuozzo Containers antigamente conhecido como SWsoft, é um exemplo de produto que usa a virtualização em nível de sistema operacional. Foi utilizado por muitos Web Hostings.

 

Virtualização em nível de Aplicação

Todas as técnicas de virtualização discutidos até este ponto têm o mesmo objetivo, aumentar o número de partições seguras, isolado em execução simultaneamente em hardware físico para maximizar o uso da CPU, armazenamento, rede, memória e outros recursos. Embora possam ser aplicados em um ambiente desktop, esses são principalmente voltadas para a solução de gestão de recursos em ambientes de servidor entretanto esses não abordam problemas de gerenciamento de aplicativos de desktop. Virtualização em nível de aplicação é uma tecnologia que é voltado para a separação e isolamento de aplicações “client-side” rodando no sistema operacional local. Conforme a figura abaixo, aplicações são isoladas em um ambiente virtual em camadas entre o sistema operacional e a pilha de aplicação. O ambiente virtual carrega a aplicação, isola a aplicação de outros aplicativos e do sistema operacional e também impede que o aplicativo modifique recursos locais, como arquivos e configurações do registro. Os aplicativos podem ler informações de arquivos e de registros do sistema local, mas versões graváveis destes recursos são mantidos dentro do ambiente virtual. Na verdade, o aplicativo nunca precisa ser instalado localmente no desktop; em vez disso, os bits de código podem ser dinamicamente transmitidos e armazenados em cache no ambiente virtual conforme novas partes do aplicativo são necessárias.

Em 2006, a Microsoft entrou no mercado de virtualização em nível de aplicação com a aquisição da Softricity e sua linha de produtos SoftGrid. O software Microsoft SoftGrid Application Virtualization for Desktops roda no desktop local e mantém um sistema de registro, sistema de arquivos, e outras configurações em um ambiente virtual, sendo esses entregues para a aplicação conforme sua necessidade. Atualmente existem diversos produtos para a virtualização em nível de aplicação e essa linha é conhecida como Microsoft Application Virtualization v4.6.

GPResult não apresenta configurações de computadores

Olá sobreviventes,

Um cliente estava precisando consultar as diretivas aplicadas em um servidor, contudo ao executar o GPRESULT /R somente eram apresentadas as diretivas de usuários. Fiquei intrigado com o mesmo e ao realizar acesso remoto ao servidor observei que a conta que ele estava usando possuía privilegio administrativo, mas como o servidor é um WIN2008-R2, por padrão, o UAC estava ativado. Por curiosidade, executei o GPRESULT com a seguinte sintaxe: GPRESULT /R /SCOPE COMPUTER, logo de cara recebi o seguinte erro conforme tela abaixo:

ERRO: Acesso negado.

Evidentemente o erro estava relacionado ao modo administrativo. Ao executar o CMD em modo administrativo e ao executar novamente o GPRESULT /R o mesmo apresentou os resultados esperados. Na documentação da Microsoft – http://technet.microsoft.com/en-us/library/cc733160%28WS.10%29.aspx – apesar de não sugerir o mesmo, devemos lembrar que muitas operações que requerem certas consultas específicas ao AD requerem modo administrativo.

Resumindo, execute o CMD em modo administrativo, desde que a conta seja DOMAIN ADMIN e execute o GPRESULT /R, não há a necessidade de especificar o escopo.

Abraços e até o próximo resgate.

Dica do Dia – Provedor Gratuito para Speedy

Olá Sobreviventes…

Gostaria de compartilhar uma dica, aliás, por incrível que pareça deu enorme trabalho para encontrar um provedor gratuito para o “maravilho” Speedy. Como muitos devem saber o uso do provedor de conteúdo simplesmente é uma imposição da ANATEL, e não existe nenhuma questão técnica ou qualquer outro quesito para a obrigação da utilização desse serviço, ou seja, as agências estatais que deveriam defender o interesse da população simplesmente são os mentores da desordem desse país, mas deixando de lado o meu protesto, vamos voltar ao foco deste post.

Obviamente qualquer um poderia simplesmente digitar “provedor gratuito speedy” no Google, e evidentemente o mesmo eu fiz, contudo recebi diversas sugestões de links de fóruns, mas nenhum link apresentava exatamente o que eu queria e quando achava algum link que levaria para um “provedor de conteúdo” a página não existia ou algum outro erro.]

Lembrei que um dia alguém havia comentado que a GLOBO.COM oferecia provedor de conteúdo gratuito para uso do Speedy. Novamente no Google, após algumas tentativas encontrei diversos links com informações sobre o provedor gratuito da GLOBO.COM, mas o que realmente eu queria era achar um link para preencher o cadastro para utilizar esse serviço. A procura estava um tanto confusa que acabei até mesmo criando uma conta de e-mail na GLOBO.COM, coisa que descobri depois não haver necessidade.

Após algumas tentativas, ou melhor, após quase uma hora de buscas finalmente encontrei o dito cujo link de cadastro:

http://assine.globo.com/globocom/banda-larga-basico?origemId=260

Esse link direcionara para o formulário correto de cadastro para uso somente do provedor gratuito, sem nenhuma contratação de qualquer espécie de serviço.

 

Abraços e até o próximo resgate.

Magno Alberto

Novo nome para o Kaspersky Administration Kit

Olá Sobreviventes!

Recentemente precisei baixar o Kaspersky Administration Kit, também conhecido com KAV Admin Kit, contudo não estava conseguindo. Após algumas pesquisas mais aprofundadas, descobri que o Admin Kit foi substituído pelo Kaspersky Security Center. Após algumas observações desse “novo produto”, para mim, somente foi uma mudança de nome.

Kaspersky Security Center: http://www.kaspersky.com/downloads/productupdates/security-center

 

Abraços e até o próximo resgate.

Magno Alberto

Acorda Microsoft… Está chegando VMware vSphere 5

Olá Sobreviventes…

Recordo-me como era apaixonado pela idéia da Microsoft oferecer ao mercado seu próprio hypervisor. Gostava muito (e ainda gosto) da tecnologia VMware mas acreditava que a Microsoft estava perdendo um nicho de mercado que, para mim, estava óbvio que seria o que é hoje.

Com o lançamento do Windows Server 2008, já estava com as pontas dos dedos coçando para poder realizar alguma implantação com o Hyper-V, mas lançar ainda em fase beta, parecia mais uma piada ou mesmo uma afronta a todos aqueles que são ou eram evangelistas Microsoft, ok… eu preciso confessar, eu tinha um apreço acima da média pela Microsoft. =/

Logo após o lançamento oficial do Hyper-V e seus inúmeros hotfixes pós-instalação, não tive nenhuma oportunidade de realizar uma implantação para ambiente corporativo mas já estava encontrando informações que a MS estava desenvolvendo em ritmo acelerado a nova versão do Hyper-V e que em pouco tempo estaria disponível. Na época eu achava: “Oohh, agora a MS vai surrar a VMware”, mas no fundo ficava aquela pulga: “Por que a MS estaria já desenvolvendo uma nova versão se male-male havia saido o Hyper-V1?” Qualquer defensor da MS diria que isso era para mostrar o poder de fogo da MS mas aqueles que não estava nas clouds diria que eles lançaram um produto mal-feito para os defensores da MS quebrarem a cara com os seus clientes enquanto eles estavam tentando desenvolver algo mais competitivo. Bem… obviamente eu era daqueles que quebravam a cara diante do cliente.

Independentemente de qual seria a verdade, eu estava torcendo para ter a oportunidade no menor tempo possível experimentar esse novo produto. Era tanto a minha ansiedade que entrava no canal Virtualization da MS todos os dias para acompanhar a liberação do Hyper-V2. Lembro de ficar lendo todos os comparativos entre Hyper-V e VMware, de como era lindo esse mundo, onde você poderia implantar necessários complexos de virtualização com o Hyper-V Server 2008 R2 praticamente sem custo para o cliente, que isso e aquilo…

Em todas os comparativos da Microsoft, obviamente eles demonstram que o Hyper-V é superior em quase tudo em relação com a VMware, mas a única vantagem real é custo, isso considerando o Hyper-V Server e o Live Migration em comparação com o vSphere e vMotion, evidentemente comparar produto gratuito contra produto pago é muito fácil, mas o cliente não precisa saber que a VMware tem uma versão gratuita, né?!?!

Tudo bem… realmente precisamos mostrar as vantagens em relação ao concorrente, mas até onde é justo a manipulação ou ocultar informação? A Microsoft não gosta de falar que a VM em Hyper-V está limitado a somente 4 processadores nem tão pouco sobre o desempenho inferior da VM em comparação com uma VM no VMware ou mesmo sobre o eterno problema do VMBUS mesmo com todos os hotfixes lançados (para aqueles que não sabem, é um bug onde VM ao receber alta carga na rede, o VMBUS falha e a VM fica completamente sem acesso a rede, sendo necessário realizar reboot da VM).

Rapidamente li em alguns artigos que a MS está trabalhando no novo Hyper-V, não posso fazer nenhum comentário pois não aprofunei nas pesquisas mas acho que o Big Bear de Redmond deve estar hibernando ou os engenheiros de desenvolvimento estão usando a criatividade para elaborar materiais comparativos de Hyper-V e VMware, mas desenvolver um software maduro e robusto só saberemos mesmo quando sair essa nova versão, enquanto isso a VMware está renovando a tecnologia de virtualização.

Uma das coisas que eu considerava um absurto em qualquer tecnologia de virtualização era a impossiblidade de virtualizar o próprio hypervisor. Uns diriam, é devido aos RINGS, outros diriam que é devido as instruções Intel VT e AMD-V, e outros simplesmente diram que é impossível virtualizar a virtualização, blah, blah, blah…

O que muitos esquecem, tudo fundamentalmente é BIT, seja as instruções do hardware ou mesmo o próprio software, tudo depende do bom e velho 0 e 1. Com o lançamento do VMware Workstation 7.1 foi possível instalar o próprio vSphere 4 em uma VM. Ohhhh… finalmente minhas preces estavam começando a serem atendidas, alguém teve a incrível idéia que isso seria ótimo para, por exemplo, permitir profissionais de TI simularem e estudarem implantações de um hypervisor sem mesmo precisar de um computador dedicado a isso, mas infelizmente estava limitado a somente ao vSphere 4 sobre o Workstation.

Mas não muito longe desse marco histórico, a VMware ousa novamente inovar. Está para ser lançado possivelmente no terceiro trimestre desse ano a nova versão do seu hypervisor, o VMware vSphere 5. Entre todos os novos recursos, um dos mais excitantes é a possibilidade de virtualizar o próprio Hyper-V, ou seja, será possível executar VMs de Hyper-V dentro de uma VM da VMware.

Provalmente na prática isso não ofereça nenhuma vantagem, mas isso realmente não importa, o que importa é poder oferecer um produto com novas tecnologias e capacidades e não ficar limitado as mesmices da virtualização. Aliás, consigo ver situações práticas para essa possibilidade: Simular a própria instalação de diversos Hyper-V para cenários de HA (high availability) ou mesmo verificar se aquele novo hotfix para Hyper-V realmente irá resolver ou se irá piorar o bug do VMBUS ou mesmo estudar para o exame TS 70-652, onde requer dois ou mais Hyper-V para realizar os laboratórios. =)

Para mim, essa evolução demonstra como a tecnologia VMware está a frente da Microsoft. Enquanto isso os engenheiros da MS preferem usar seus talentos para desenvolver propaganda exaltando o Hyper-V como sendo o supremus-visor isso sem contar com os comparativos do Hyper-V + SystemCenter em relação vSphere, mas deixa pra lá…

Realmente desejo que a Microsoft saia das clouds e volte a ter o pé no chão e reveja o que ela anda oferecendo ao mercado. Todos e digo todos sabemos que ela tem condições de oferecer um produto altamente competitivo mas acho que ela foca demais em propaganda e deixa os seus parceiros com o hyper-pepino na mão.

How to Enable Support for Nested 64bit & Hyper-V VMs in vSphere 5
http://www.virtuallyghetto.com/2011/07/how-to-enable-support-for-nested-64bit.html#comment-form

Five features you should know about in VMware’s vSphere 5
http://www.zdnet.com/photos/five-features-you-should-know-about-in-vmwares-vsphere-5/6282963?tag=photo-frame%3Bget-photo-roto

Abraços e até o próximo resgate!
Magno Alberto

Script para defragmentar múltiplos VMDK de VMs

Olá sobreviventes!

Gostaria de compartilhar um script que desenvolvi a algum tempo. Apesar de não exigir muito esforço para desenvolver, nada melhor como encontar um script pronto e testado.

A idéia desse script é defragmentar múltiplos VMDKs sequencialmente, ou seja, em vez de executar o utilitário vmware-vdiskmanager.exe e informar o nome de um único VMDK. Essa condição de defragmentar vários VMDKs é muito útil para quem usa o VMWARE para laboratório de testes pois é muito desgastante usar a console e executar o comando DEFRAGMENT para cada VMDK, principalmente para aqueles que geram muitos snapshots.

Na época tentei desenvolver o script com o comando FOR mas não dava muito certo e depois acabei lembrando do utilitário FORFILES que foi perfeito para o sucesso do script.


set PATH=%PATH%;c:\Program Files (x86)\VMware\VMware Workstation
forfiles /P . /S /M *.vmdk /c "cmd /c vmware-vdiskmanager.exe -d @path"


Basicamente o script é divido em 3 partes:

A primeira define a variável de sistema PATH para informar o caminho do utilitário vmware-vdiskmanager.exe. Esse caminho é o diretório padrão da instalação, caso a instalação do VMWARE esteja em outro local é necessário alterar o caminho.

A segunda parte é utilizar o FORFILES para localizar todos arquivos .VMDK e esse resultado é adicionado a variável do @path do FORFILES.

A terceira parte, o FORFILES executa o utilitário vmware-vdiskmanager.exe, que informa o caminho do .VMDK necessário ser defragmentado. Evidentemente utilizei o switch -d que informa ao vmware-vdiskmanager.exe que modo de operação é defragmentar arquivo.

Abraços e até o próximo resgate!
Magno Alberto

Emulador de Rede

Olá Sobreviventes!

Adoro VMs!!! Por muitos anos que utilizo essa maravilha em forma de software. Como é ótimo você poder simular uma implantação ou testar algum software e com um simples ‘revert snapshot’ o seu laboratório retorna para o ponto que foi marcado. Mas devo ser sincero, apesar de ser profissional Microsoft com diversas certificações em seus produtos, realmente tenho uma afinidade especial com a VMware, precisamente com o o recurso TEAM do VMware Workstation, contudo hoje não irei jogar confetes nesse software.

A muito tempo tenho ficado intrigado com um comportamento errôneo (assim eu considerava) no LAN SEGMENTS (Propriedades do TEAM). Nessa guia existe alguns controles  que permitem definir a largura de banda (bandwidth) e um porcentual de perda de pacotes (packet loss), contudo em todas as versões (acho que desde a 5.5 em diante) esse recurso NUNCA funcionou. Fiz diversas pesquisas, mas admito que nunca fui tão afundo, mas realmente fiz diversas pesquisas para saber onde estava o problema para esses controles não apresentarem o resultado esperado.

Esses dias estava querendo fazer um LAB mais avançado com o DFS-R em um ambiente de WAN e para isso precisava de alguma forma as VMs em rede tivessem baixa velocidade e também com perda de pacotes. Obviamente imaginei ussar esse recurso do VMware Workstation mas como já sabia que não iria funcionar, pesquisei algumas alternativas e entre diversos softwares pagos e gratuitos, fiquei interessado em um produto da Microsoft chamado “Network Emulator Toolkit”. Basicamente ele oferece entre alguns recursos, exatamente o que eu estava precisando, uma forma de limitar a banda entre as VMs. Ainda não fiz um teste mas por acaso encontrei alguns webcasts que demonstram o funcionamento desse programa. Segue abaixo link para download tanto da versão 32-bits e 64-bits. Realmente foi “trampo’ achar o mesmo, não encontrava em lugar algum.

https://skydrive.live.com/?cid=9A33ADEBDD8B2072&id=9A33ADEBDD8B2072!537

Voltando ao comportamento do LAN SEGMENTS do VMware, acidentalmente encontrei a explicação referente ao não funcionamento do controle de banda. No fórum da VMware havia diversas queixas sobre o mesmo e pela falta de explicação sobre esse comportamento, mas somente em um post estava a explicação: O recurso de controle da banda somente funciona se as VMs forem iniciadas através do POWER ON do TEAM e não através do POWER ON de cada VM. — Rá! pegadinha do malandro, yeh yeah!

Com essa descoberta de anos de pesquisas, qualquer um teria pensado que eu já iria testar para realmente ver funcionar, mas fiquei tão incomodado que preferi usar pesquisar outra forma de esse controle sem ter que iniciar todas as VMs do TEAM, que no meu ponto de vista é ESTÚPIDO DEMAIS.

Após algumas consultas ao Grande Oráculo da ilha, encontrei algumas síntaxes de ajuste fino para a configuração de rede. Essas síntaxes devem serem inseridas no arquivo de configuração da VM (.VMX), com o respectivo valor desejado:

ethernet0.numRecvBuffers
ethernet0.numXmitBuffers
ethernet0.rxbw.limit
ethernet0.rxbw.queuesize
ethernet0.rxfi.droprate
ethernet0.rxfi.dropsize
ethernet0.txbw.limit
ethernet0.txbw.queuesize
ethernet0.txfi.droprate
ethernet0.txfi.dropsize
ethernet0.noReceiveAfterSend
ethernet0.yieldAfterSend
ethernet0.flashWriteable
ethernet0.forcedToBridged

Abraços e até o próximo resgate.
Magno Alberto