Binários QEMU para Windows (32 bits) Este site fornece QEMU relacionados documentação e binários (instaladores) para 32 bits e 64 bits versões do Microsoft Windows. Os instaladores são gerados a partir das minhas últimas fontes QEMU e atualizados com freqüência. Consulte as instruções de compilação para obter detalhes. O QEMU para Windows é um software experimental e pode conter até bugs sérios, então use os binários por sua conta e risco. História 2016-09-03. Novos instaladores QEMU (2.7.0). 2016-08-31. Novos instaladores QEMU (2.7.0-rc5). 2016-08-23. Novos instaladores QEMU (2.7.0-rc4). 2016-08-17. Novos instaladores QEMU (2.7.0-rc3). 2016-08-08. Novos instaladores QEMU (2.7.0-rc2). Transições de registro ATA fixas. 2016-07-30. Novos instaladores QEMU (2.7.0-rc1). 2016-07-23. Novos instaladores QEMU (2.7.0-rc0). Agora envia eventos de rastreamento para stderr. 2016-05-23. Novos instaladores QEMU. Várias correções. 2016-05-16. Novos instaladores QEMU (2.6.0). Fixed Pentium III SSE. 2016-05-14. Novos instaladores QEMU (2.6.0). 2016-05-11. Novos instaladores QEMU (2.6.0-rc5). 2016-05-02. Novos instaladores QEMU (2.6.0-rc4). 2016-04-22. Novos instaladores QEMU (2.6.0-rc3). 2016-04-14. Novos instaladores QEMU (2.6.0-rc2). Rede fixa. 2016-04-06. Novos instaladores QEMU (2.6.0-rc1). Rede quebrada. 2016-04-01. Novos instaladores QEMU (2.6.0-rc0). Quebrado de rede, quebrado Pentium III SSE. 2016-03-03. Novos instaladores QEMU. Fixa, primeira versão com suporte para Raspberry Pi 1 e 2. 2016-02-15. Novos instaladores QEMU. Relatado para ser buggy, sem janela SDL. 2015-12-16. Novos instaladores QEMU (2.5.0). 2015-12-12. Novos instaladores QEMU (2.5.0-rc4). 2015-12-08. Novos instaladores QEMU (2.5.0-rc3). 2015-11-27. Novos instaladores QEMU (2.5.0-rc2). Emulação de sistema MIPS fixa. 2015-11-15. Novos instaladores QEMU (2.5.0-rc0). 2015-08-11. Novos instaladores QEMU (2.4.0). 2015-08-05. Novos instaladores QEMU (2.4.0-rc4). 2015-07-31. Novos instaladores QEMU (2.4.0-rc3). Rede fixa. 2015-07-26. Novos instaladores QEMU (2.4.0-rc2). Compilação fixa para 32 e 64 bits. 2015-07-22. Novos instaladores QEMU (2.4.0-rc2). Buggy, não use. 2015-07-18. Novos instaladores QEMU (2.4.0-rc1). Buggy, não use. 2015-05-10. Novos instaladores QEMU (2.3.0). Lista fixa de DLLs incluídas. 2015-05-03. Novos instaladores QEMU (2.3.0). Agora construído com Debian Jessie. Adicionado chave de registro DisplayVersion. 2015-04-24. Novos instaladores QEMU (2.3.0). 2015-04-13. Novos instaladores QEMU (2.3.0-rc3). 2015-04-02. Novos instaladores QEMU (2.3.0-rc2). 2015-03-21. Novos instaladores QEMU (2.3.0-rc0). 2014-12-10. Novos instaladores QEMU (2.2.0). 2014-12-05. Novos instaladores QEMU (2.2.0-rc5). 2014-12-01. Novos instaladores QEMU (2.2.0-rc4). 2014-11-26. Novos instaladores QEMU (2.2.0-rc3). 2014-11-20. Novos instaladores QEMU (2.2.0-rc2). 2014-11-12. Novos instaladores QEMU (2.2.0-rc1). 2014-11-07. Novos instaladores QEMU (2.2.0-rc0). 2014-08-01. Novos instaladores QEMU (2.1.0). 2014-07-29. Novos instaladores QEMU (2.1.0-rc4). 2014-07-22. Novos instaladores QEMU (2.1.0-rc3). 2014-07-15. Novos instaladores QEMU (2.1.0-rc2). Emulação do sistema ARM fixo. 2014/07/09. Todas as emulações do sistema ARM do QEMU para Windows estão quebradas desde outubro de 2012 (commit d8cdd46def3aa970560932536db40e6e747bf809). 2014-07-08. Novos instaladores QEMU (2.1.0-rc1). 2014-07-02. Novos instaladores QEMU (2.1.0-rc0). 2014-05-29. Novos instaladores QEMU. Versão fixa de 64 bits. 2014-05-28. Todas as versões de 64 bits do QEMU para Windows estão quebradas desde o final de agosto de 2013. 2014-05-17. Novos instaladores QEMU. Corrigido E / s de disco quebrado. Adicionado faltando DLL. Agora usa o GTK 3.0 para a versão de 64 bits. 2014-05-10. Novos instaladores QEMU. Muito mais rápido graças ao gpoll fixo. Problema conhecido: Disk I / O está quebrado. 2014-04-18. Novos instaladores QEMU (2.0.0). 2014-04-14. Novos instaladores QEMU (2.0.0-rc3). 2014-04-09 Novos instaladores QEMU (2.0.0-rc2). 2014-04-04. Novos instaladores QEMU (2.0.0-rc1). Corrigido dll ausente. 2014-03-14. Novos instaladores QEMU (2.0.0-rc0). Problema conhecido: libgccssjlj-1.dll está ausente. 2014-03-02. Novos instaladores QEMU. Problema conhecido: libgccssjlj-1.dll está ausente. 2014-02-06. Novos instaladores QEMU. 2014-01-18. Novos instaladores QEMU. 2013-11-28. Novos instaladores QEMU (1.7.0). 2013-11-26. Novos instaladores QEMU (1.7.0-rc2). 2013-11-21. Novos instaladores QEMU (1.7.0-rc1). Opção do compilador removida - fstack-protector-all. Isso reduz o tamanho do código e pode melhorar o desempenho um pouco. 2013-11-18. Novos instaladores QEMU (1.7.0-rc0). As emulações do sistema agora suportam maldições. A entrada de teclado no GTK deve ser corrigida. 2013-08-17. Novos instaladores QEMU. Adicionado emulação de sistema experimental para Raspberry Pi (baseado no código de Gregory Estrade). 2013-06-16. Novos instaladores QEMU (1.5.50). Erros conhecidos:.PhysicalDrive0 não funciona. 2012-12-04. Novos instaladores QEMU (1.3.50.0). 2012-11-25. Novos instaladores QEMU (1.2.90.0) (32 e 64 bits). 2011-11-19. Novo instalador QEMU (0.15.92.0). 2011-03-13. Novo instalador QEMU (0.14.50.0) (apenas 32 bits). Sobre mim O proprietário deste site é Stefan Weil, Kirchenstraszlige 5, D-68526 Ladenburg. Posso ser contatado por e-mail ou e-mail (qemu-website no weilnetz dot de). AcknowledgementQEMU Binários para Windows (64 bits) Aqui você obtém binários relacionados ao QEMU para versões de 64 bits do Microsoft Windows. Este site fornece QEMU relacionados documention e binários (instaladores) para 32 bits e 64 bits versões do Microsoft Windows. Os instaladores são gerados a partir das minhas últimas fontes QEMU e atualizados com freqüência. Consulte as instruções de compilação para obter detalhes. O QEMU para Windows é um software experimental e pode conter até bugs sérios, então use os binários por sua conta e risco. História 2016-09-03. Novos instaladores QEMU (2.7.0). 2016-08-31. Novos instaladores QEMU (2.7.0-rc5). 2016-08-23. Novos instaladores QEMU (2.7.0-rc4). 2016-08-17. Novos instaladores QEMU (2.7.0-rc3). 2016-08-08. Novos instaladores QEMU (2.7.0-rc2). Transições de registro ATA fixas. 2016-07-30. Novos instaladores QEMU (2.7.0-rc1). 2016-07-23. Novos instaladores QEMU (2.7.0-rc0). Agora envia eventos de rastreamento para stderr. 2016-05-23. Novos instaladores QEMU. Várias correções. 2016-05-16. Novos instaladores QEMU (2.6.0). Fixed Pentium III SSE. 2016-05-14. Novos instaladores QEMU (2.6.0). 2016-05-11. Novos instaladores QEMU (2.6.0-rc5). 2016-05-02. Novos instaladores QEMU (2.6.0-rc4). 2016-04-22. Novos instaladores QEMU (2.6.0-rc3). 2016-04-14. Novos instaladores QEMU (2.6.0-rc2). Rede fixa. 2016-04-06. Novos instaladores QEMU (2.6.0-rc1). Rede quebrada. 2016-04-01. Novos instaladores QEMU (2.6.0-rc0). Quebrado de rede, quebrado Pentium III SSE. 2016-03-03. Novos instaladores QEMU. Fixa, primeira versão com suporte para Raspberry Pi 1 e 2. 2016-02-15. Novos instaladores QEMU. Relatado para ser buggy, sem janela SDL. 2015-12-16. Novos instaladores QEMU (2.5.0). 2015-12-12. Novos instaladores QEMU (2.5.0-rc4). 2015-12-08. Novos instaladores QEMU (2.5.0-rc3). 2015-11-27. Novos instaladores QEMU (2.5.0-rc2). Emulação de sistema MIPS fixa. 2015-11-15. Novos instaladores QEMU (2.5.0-rc0). 2015-08-11. Novos instaladores QEMU (2.4.0). 2015-08-05. Novos instaladores QEMU (2.4.0-rc4). 2015-07-31. Novos instaladores QEMU (2.4.0-rc3). Rede fixa. 2015-07-26. Novos instaladores QEMU (2.4.0-rc2). Compilação fixa para 32 e 64 bits. 2015-07-22. Novos instaladores QEMU (2.4.0-rc2). Buggy, não use. 2015-07-18. Novos instaladores QEMU (2.4.0-rc1). Buggy, não use. 2015-05-10. Novos instaladores QEMU (2.3.0). Lista fixa de DLLs incluídas. 2015-05-03. Novos instaladores QEMU (2.3.0). Agora construído com Debian Jessie. Adicionado chave de registro DisplayVersion. 2015-04-24. Novos instaladores QEMU (2.3.0). 2015-04-13. Novos instaladores QEMU (2.3.0-rc3). 2015-04-02. Novos instaladores QEMU (2.3.0-rc2). 2015-03-21. Novos instaladores QEMU (2.3.0-rc0). 2014-12-10. Novos instaladores QEMU (2.2.0). 2014-12-05. Novos instaladores QEMU (2.2.0-rc5). 2014-12-01. Novos instaladores QEMU (2.2.0-rc4). 2014-11-26. Novos instaladores QEMU (2.2.0-rc3). 2014-11-20. Novos instaladores QEMU (2.2.0-rc2). 2014-11-12. Novos instaladores QEMU (2.2.0-rc1). 2014-11-07. Novos instaladores QEMU (2.2.0-rc0). 2014-08-01. Novos instaladores QEMU (2.1.0). 2014-07-29. Novos instaladores QEMU (2.1.0-rc4). 2014-07-22. Novos instaladores QEMU (2.1.0-rc3). 2014-07-15. Novos instaladores QEMU (2.1.0-rc2). Emulação do sistema ARM fixo. 2014-07-09. Todas as emulações do sistema ARM do QEMU para Windows estão quebradas desde outubro de 2012 (commit d8cdd46def3aa970560932536db40e6e747bf809). 2014-07-08. Novos instaladores QEMU (2.1.0-rc1). 2014-07-02. Novos instaladores QEMU (2.1.0-rc0). 2014-05-29. Novos instaladores QEMU. Versão fixa de 64 bits. 2014-05-28. Todas as versões de 64 bits do QEMU para Windows estão quebradas desde o final de agosto de 2013. 2014-05-17. Novos instaladores QEMU. Corrigido E / s de disco quebrado. Adicionado faltando DLL. Agora usa o GTK 3.0 para a versão de 64 bits. 2014/05-10. Novos instaladores QEMU. Muito mais rápido graças ao gpoll fixo. Problema conhecido: Disk I / O está quebrado. 2014-04-18. Novos instaladores QEMU (2.0.0). 2014-04-14. Novos instaladores QEMU (2.0.0-rc3). 2014-04-09 Novos instaladores QEMU (2.0.0-rc2). 2014-04-04. Novos instaladores QEMU (2.0.0-rc1). Corrigido dll ausente. 2014-03-14. Novos instaladores QEMU (2.0.0-rc0). Problema conhecido: libgccssjlj-1.dll está ausente. 2014-03-02. Novos instaladores QEMU. Problema conhecido: libgccssjlj-1.dll está ausente. 2014-02-06. Novos instaladores QEMU. 2014-01-18. Novos instaladores QEMU. 2013-11-28. Novos instaladores QEMU (1.7.0). 2013-11-26. Novos instaladores QEMU (1.7.0-rc2). 2013-11-21. Novos instaladores QEMU (1.7.0-rc1). Opção de compilador removida - fstack-protector-all. Isso reduz o tamanho do código e pode melhorar o desempenho um pouco. 2013-11-18. Novos instaladores QEMU (1.7.0-rc0). As emulações do sistema agora suportam maldições. A entrada de teclado no GTK deve ser corrigida. 2013-08-17. Novos instaladores QEMU. Adicionado emulação de sistema experimental para Raspberry Pi (baseado no código de Gregory Estrade). 2013-06-16. Novos instaladores QEMU (1.5.50). Erros conhecidos:.PhysicalDrive0 não funciona. 2012-12-04. Novos instaladores QEMU (1.3.50.0). 2012-11-25. Novos instaladores QEMU (1.2.90.0) (32 e 64 bits). 2011-11-19. Novo instalador QEMU (0.15.92.0). 2011-03-13. Novo instalador QEMU (0.14.50.0) (apenas 32 bits). Sobre mim O proprietário deste site é Stefan Weil, Kirchenstraszlige 5, D-68526 Ladenburg. Posso ser contatado por e-mail ou e-mail (qemu-website no weilnetz dot de). AcknowledgementAccording ao QEMU sobre a página. QEMU é um emulador de máquina genérica e de código aberto e virtualizador. Quando usado como um emulador de máquina, o QEMU pode executar SOs e programas feitos para uma máquina (por exemplo, uma placa ARM) em uma máquina diferente (por exemplo, seu PC x86). Usando a tradução dinâmica, ele consegue um desempenho muito bom. QEMU pode usar outros hypervisors como Xen ou KVM para usar extensões de CPU (HVM) para virtualização. Quando usado como um virtualizador, QEMU atinge perto performances nativas executando o código de convidado diretamente na CPU do host. Conteúdo Instalação Instale o pacote qemu e abaixo pacotes opcionais para suas necessidades: Front-ends gráficos para QEMU Ao contrário de outros programas de virtualização, como VirtualBox e VMware. O QEMU não fornece uma GUI para gerenciar máquinas virtuais (diferente da janela que aparece ao executar uma máquina virtual), nem fornece uma maneira de criar máquinas virtuais persistentes com configurações salvas. Todos os parâmetros para executar uma máquina virtual devem ser especificados na linha de comando em cada lançamento, a menos que você tenha criado um script personalizado para iniciar suas máquinas virtuais. No entanto, existem vários front-ends GUI para QEMU: Front-ends adicionais com suporte QEMU estão disponíveis para libvirt. Criando um novo sistema virtualizado Criando uma imagem de disco rígido Dica: Consulte o Wikilivros QEMU para obter mais informações sobre imagens QEMU. Para executar QEMU você precisará de uma imagem de disco rígido, a menos que você esteja inicializando um sistema ao vivo a partir do CD-ROM ou da rede (e não fazê-lo para instalar um sistema operacional em uma imagem de disco rígido). Uma imagem de disco rígido é um arquivo que armazena o conteúdo do disco rígido emulado. Uma imagem de disco rígido pode ser raw. De modo que é literalmente byte-by-byte o mesmo que o hóspede vê, e sempre usará a capacidade total do disco rígido do hóspede no host. Esse método fornece o mínimo de sobrecarga de E / S, mas pode desperdiçar muito espaço, pois o espaço não utilizado no convidado não pode ser usado no host. Em alternativa, a imagem do disco rígido pode estar num formato tal como qcow2 que só aloca espaço para o ficheiro de imagem quando o sistema operativo convidado realmente escreve para esses sectores no seu disco rígido virtual. A imagem aparece como o tamanho completo para o sistema operacional convidado, mesmo que ele pode ocupar apenas uma quantidade muito pequena de espaço no sistema host. Usar esse formato em vez de raw provavelmente afetará o desempenho. QEMU fornece o comando qemu-img para criar imagens de disco rígido. Por exemplo, para criar uma imagem de 4 GB no formato raw: Você pode usar - f qcow2 para criar um disco qcow2 em vez disso. Nota: Você também pode simplesmente criar uma imagem bruta criando um arquivo do tamanho necessário usando dd ou fallocate. Aviso: Se você armazenar as imagens de disco rígido em um sistema de arquivos Btrfs, você deve considerar a desativação de Copy-on-Write para o diretório antes de criar qualquer imagem. Sobreposição de imagens de armazenamento Você pode criar uma imagem de armazenamento uma vez (a imagem de apoio) e manter QEMU manter mutações para esta imagem em uma imagem de sobreposição. Isso permite que você reverta para um estado anterior dessa imagem de armazenamento. Você pode reverter criando uma nova imagem de sobreposição no momento em que deseja reverter, com base na imagem de apoio original. Para criar uma imagem de sobreposição, emita um comando como: Depois disso, você pode executar o QEMU VM como de costume (consulte Executando o sistema virtualizado): A imagem de apoio será deixada intacta e as mutações nesse armazenamento serão gravadas no arquivo de imagem de sobreposição. Quando o caminho para a imagem de apoio é alterado, o reparo é necessário. Aviso: O caminho do sistema de arquivos absoluto de imagens de backup é armazenado no arquivo de imagem de sobreposição (binário). Alterar o caminho das imagens de apoio requer algum esforço. Certifique-se de que o caminho original de imagens de apoio ainda leva a esta imagem. Se necessário, faça um link simbólico no caminho original para o novo caminho. Em seguida, emita um comando como: A seu critério, você pode alternativamente realizar uma rebase inseguro onde o caminho antigo para a imagem de apoio não está marcada: Redimensionar uma imagem Aviso: Redimensionar uma imagem contendo um sistema de arquivos de inicialização NTFS poderia tornar o sistema operacional instalado Ele não inicializável. Para obter uma explicação completa e solução alternativa, consulte 1. O executável qemu-img tem a opção de redimensionamento, que permite o redimensionamento fácil de uma imagem de disco rígido. Ele funciona para raw e qcow2. Por exemplo, para aumentar o espaço da imagem em 10 GB, execute: Depois de ampliar a imagem do disco, você deve usar o sistema de arquivos e as ferramentas de particionamento dentro da máquina virtual para realmente começar a usar o novo espaço. Ao encolher uma imagem de disco, você deve primeiro reduzir os sistemas de arquivos e tamanhos de partição alocados usando o sistema de arquivos e as ferramentas de particionamento dentro da máquina virtual e, em seguida, encolher a imagem do disco de acordo, caso contrário, a redução da imagem do disco resultará na perda de dados. Para instalar um sistema operacional em sua imagem de disco, você precisa do meio de instalação (por exemplo, disco ótico, unidade USB ou imagem ISO) para o sistema operacional. O meio de instalação não deve ser montado porque QEMU acessa a mídia diretamente. Dica: Se estiver usando um disco ótico, é uma boa idéia primeiro despejar a mídia para um arquivo, porque isso melhora o desempenho e não exige que você tenha acesso direto aos dispositivos (ou seja, você pode executar QEMU como um usuário comum Sem ter que alterar permissões de acesso no arquivo de dispositivo de mídia). Por exemplo, se o nó de dispositivo de CD-ROM é nomeado / dev / cdrom. Você pode despejá-lo em um arquivo com o comando: Instalando o sistema operacional Esta é a primeira vez que você precisará iniciar o emulador. Para instalar o sistema operacional na imagem de disco, você deve anexar a imagem de disco e a mídia de instalação à máquina virtual e fazer a inicialização a partir da mídia de instalação. Para obter mais informações sobre o carregamento de outros tipos de mídia (como disquetes, imagens de disco ou unidades físicas) e Executar aplicativos virtualizados, consulte qemu (1), por exemplo, em i386 convidados, para instalar a partir de um arquivo ISO inicializável como CD-ROM e uma imagem de disco bruta. Outras opções úteis. Após a conclusão do sistema operacional, a imagem QEMU pode ser inicializada diretamente (consulte Executando o sistema virtualizado). Aviso: Por padrão, apenas 128 MB de memória são atribuídos à máquina. A quantidade de memória pode ser ajustada com a opção - m, por exemplo - m 512M ou - m 2G. Dica: Em vez de especificar - boot orderx. Alguns usuários podem se sentir mais confortável usando um menu de inicialização: - boot menuon. Pelo menos durante a configuração e experimentação. Se você precisar substituir disquetes ou CDs como parte do processo de instalação, você pode usar o monitor de máquina QEMU (pressione CtrlAlt2 na janela de máquinas virtuais) para remover e anexar dispositivos de armazenamento a uma máquina virtual. Digite o bloco de informações para ver os dispositivos de bloco e use o comando change para trocar um dispositivo. Pressione CtrlAlt1 para voltar para a máquina virtual. Executando o sistema virtualizado qemu-system-binários (por exemplo qemu-system-i386 ou qemu-system-x8664, dependendo da arquitetura dos convidados) são usados para executar o convidado virtualizado. O uso é: As opções são as mesmas para todos os binários qemu-system, veja qemu (1) para a documentação de todas as opções. Por padrão, o QEMU mostrará a saída de vídeo das máquinas virtuais em uma janela. Uma coisa a ter em mente: quando você clica dentro da janela QEMU, o ponteiro do mouse é agarrado. Para soltá-lo, pressione CtrlAltg. Aviso: QEMU nunca deve ser executado como root. Se você deve iniciá-lo em um script como root, você deve usar a opção - runas para tornar QEMU drop root privilégios. Ativando o KVM O KVM deve ser suportado pelo processador e pelo kernel, e os módulos do kernel necessários devem ser carregados. Consulte o KVM para obter mais informações. Para iniciar o QEMU no modo KVM, adicione - enable-kvm às opções de início adicionais. Para verificar se o KVM está habilitado para uma VM em execução, digite o Monitor QEMU usando CtrlAltShift2. E digite info kvm. Nota: Se você iniciar sua máquina virtual com uma ferramenta GUI e tiver um desempenho muito ruim, você deve verificar o suporte adequado do KVM, já que o QEMU pode estar caindo para a emulação de software. O KVM precisa ser habilitado para iniciar o Windows 7 eo Windows 8 adequadamente sem uma tela azul. Ativando o suporte a IOMMU (Intel VT-d / AMD-Vi) Para habilitar o IOMMU: Certifique-se de que o AMD-Vi / Intel VT-d é suportado pela CPU e ativado nas configurações do BIOS. Adicione inteliommuon se você tiver uma CPU Intel ou amdiommuon se você tiver uma CPU AMD, para os parâmetros do kernel. Reinicie e certifique-se de que o IOMMU está ativado verificando dmesg para DMAR. 0,000000 DMAR: IOMMU habilitado Adicionar iommuon ou q35, iommuon dependendo da - machine. Como opção. Movendo dados entre o host eo sistema operacional convidado Os dados de rede podem ser compartilhados entre o sistema operacional host e convidado usando qualquer protocolo de rede que possa transferir arquivos, como o NFS. SMB. NBD. HTTP, FTP. Ou SSH. Desde que tenha configurado a rede apropriadamente e habilitado os serviços apropriados. A rede padrão de usuário-modo permite que o convidado acesse o sistema operacional hospedeiro no endereço IP 10.0.2.2. Todos os servidores que estiverem sendo executados no sistema operacional host, como um servidor SSH ou SMB, estarão acessíveis neste endereço IP. Assim, nos convidados, você pode montar diretórios exportados no host via SMB ou NFS. Ou você pode acessar o servidor HTTP dos hosts, etc. Não será possível que o sistema operacional hospedeiro acesse servidores em execução no sistema operacional convidado, mas isso pode ser feito com outras configurações de rede (consulte Conexão em rede com QEMU). QEMUs O servidor SMB incorporado A documentação do QEMUs diz que tem um servidor SMB embutido, mas na verdade ele só inicia o Samba com um arquivo smb. conf gerado automaticamente localizado em / tmp / qemu-smb. Pid -0 / smb. conf e torna acessível para o hóspede em um endereço IP diferente (10.0.2.4 por padrão). Isso só funciona para a rede do usuário, e isso não é necessariamente muito útil, pois o convidado também pode acessar o serviço normal do Samba no host se você tiver configurado compartilhamentos nela. Para ativar esse recurso, inicie o QEMU com um comando como: where shareddirpath é um diretório que você deseja compartilhar entre o convidado eo host. Então, no convidado, você poderá acessar o diretório compartilhado no host 10.0.2.4 com o nome de compartilhamento qemu. Por exemplo, no Windows Explorer você iria para 10.0.2.4qemu. Nota: Se você estiver usando opções de compartilhamento várias vezes como - net user, smb shareddirpath1 - net user, smb shareddirpath2 ou - net user, smb shareddirpath1, smb shareddirpath2 então ele irá compartilhar apenas o último definido. Se você não pode acessar a pasta compartilhada eo sistema convidado é o Windows, verifique se o protocolo NetBIOS está habilitado e se um firewall não bloqueia as portas usadas pelo protocolo NetBIOS. Montando uma partição dentro de uma imagem de disco bruta Quando a máquina virtual não está sendo executada, é possível montar partições que estão dentro de um arquivo de imagem de disco bruto configurando-as como dispositivos de loopback. Isso não funciona com imagens de disco em formatos especiais, como qcow2, embora possam ser montados usando qemu-nbd. Aviso: você deve certificar-se de desmontar as partições antes de executar a máquina virtual novamente. Caso contrário, a corrupção de dados é muito provável de ocorrer. Com a especificação manual de byte offset Uma maneira de montar uma partição de imagem de disco é montar a imagem de disco em um determinado deslocamento usando um comando como o seguinte: A opção offset32256 é realmente passada para o programa losetup para configurar um dispositivo de loopback que começa em byte Offset 32256 do arquivo e continua até o fim. Este dispositivo loopback é então montado. Você também pode usar a opção sizelimit para especificar o tamanho exato da partição, mas isso geralmente é desnecessário. Dependendo da imagem do disco, a partição necessária pode não iniciar no deslocamento 32256. Executar fdisk - l diskimage para ver as partições na imagem. Fdisk dá o início e fim offsets em setores de 512 bytes, para multiplicar por 512 para obter o deslocamento correto para passar para montar. Com o módulo de loop autodetecting partições O driver de loop Linux realmente suporta partições em dispositivos de loopback, mas é desativado por padrão. Para ativá-lo, faça o seguinte: Se livrar de todos os seus dispositivos de loopback (desmontar todas as imagens montadas, etc.). Descarregue o módulo do kernel do laço e carregue-o com o conjunto de parâmetros maxpart15. Além disso, o número máximo de dispositivos de loop pode ser controlado com o parâmetro maxloop. Dica: Você pode colocar uma entrada em /etc/modprobe. d para carregar o módulo de loop com maxpart15 sempre, ou você pode colocar loop. maxpart15 na linha de comando do kernel, dependendo se você tem o módulo loop. ko integrado Seu kernel ou não. Configurar a imagem como um dispositivo de loopback: Em seguida, se o dispositivo criado foi / dev / loop0. Dispositivos adicionais / dev / loop0pX terão sido criados automaticamente, onde X é o número da partição. Esses dispositivos de loopback de partição podem ser montados diretamente. Por exemplo: Com o kpartx kpartx do pacote de multipath-tools o AUR pode ler uma tabela de partição em um dispositivo e criar um novo dispositivo para cada partição. Por exemplo: Isto irá configurar o dispositivo de loopback e criar o (s) dispositivo (s) de partição necessário (s) em / dev / mapper /. Montando uma partição dentro de uma imagem qcow2 Você pode montar uma partição dentro de uma imagem qcow2 usando qemu-nbd. Ver Wikibooks. Usando qualquer partição real como a única partição primária de uma imagem de disco rígido Às vezes, você pode querer usar uma das partições de seu sistema dentro do QEMU. Usar uma partição bruta para uma máquina virtual melhorará o desempenho, pois as operações de leitura e gravação não passarão pela camada do sistema de arquivos no host físico. Essa partição também fornece uma maneira de compartilhar dados entre o host eo convidado. No Arch Linux, os arquivos de dispositivo para partições brutas são, por padrão, propriedade do root e do grupo de discos. Se você gostaria de ter um usuário não-raiz capaz de ler e gravar em uma partição bruta, você precisará alterar o proprietário do arquivo de dispositivo de partições para esse usuário. Aviso: Embora seja possível, não é recomendável permitir que máquinas virtuais alterem dados críticos no sistema host, como a partição raiz. Você não deve montar um sistema de arquivos em uma partição de leitura e gravação no host e no convidado ao mesmo tempo. Caso contrário, haverá corrupção de dados. Depois disso, você pode anexar a partição a uma máquina virtual QEMU como um disco virtual. No entanto, as coisas são um pouco mais complicadas se você quiser ter toda a máquina virtual contida em uma partição. Nesse caso, não haveria nenhum arquivo de imagem de disco para inicializar realmente a máquina virtual, uma vez que você não pode instalar um bootloader em uma partição que é formatada como um sistema de arquivos e não como um dispositivo particionado com um MBR. Essa máquina virtual pode ser inicializada especificando o kernel e initrd manualmente ou simulando um disco com um MBR usando RAID linear. Especificando o kernel eo initrd manualmente o QEMU suporta o carregamento de kernels do Linux e discos ram do init diretamente, evitando assim os bootloaders como o GRUB. Em seguida, ele pode ser iniciado com a partição física que contém o sistema de arquivos raiz como o disco virtual, que não aparecerá para ser particionado. Isso é feito através da emissão de um comando semelhante ao seguinte: Observação: neste exemplo, são as imagens de hosts que estão sendo usados, não os convidados. Se você deseja usar as imagens dos convidados, monte / dev / sda3 somente leitura (para proteger o sistema de arquivos do host) e especifique o / full / path / to / images ou use algum kexec hackery no convidado para recarregar o arquivo Kernel (estende o tempo de inicialização). No exemplo acima, a partição física que está sendo usada para o sistema de arquivos raiz dos convidados é / dev / sda3 no host, mas aparece como / dev / sda no convidado. Você pode, naturalmente, especificar qualquer kernel e initrd que você deseja, e não apenas aqueles que vêm com o Arch Linux. Quando há vários parâmetros do kernel a serem passados para a opção - append, eles precisam ser citados usando aspas simples ou duplas. Por exemplo: Simular disco virtual com MBR usando RAID linear Uma forma mais complicada de ter uma máquina virtual usar uma partição física, mantendo essa partição formatada como um sistema de arquivos e não apenas ter a partição guest como se fosse um disco, É simular um MBR para que ele possa inicializar usando um gerenciador de inicialização como o GRUB. Você pode fazer isso usando RAID de software em modo linear (você precisa do driver de kernel linear. ko) e um dispositivo de loopback: o truque é antecipar dinamicamente um registro mestre de inicialização (MBR) para a partição real que você deseja incorporar em um QEMU raw Imagem de disco. Suponha que você tenha uma partição simples, desmontada / dev / hdaN com algum sistema de arquivos nele que você deseja fazer parte de uma imagem de disco QEMU. Primeiro, você cria algum arquivo pequeno para armazenar o MBR: Aqui, um arquivo de 16 KB (32 512 bytes) é criado. É importante não torná-lo muito pequeno (mesmo se o MBR só precisa de um único bloco de 512 bytes), uma vez que quanto menor for, menor será o tamanho do bloco do dispositivo RAID de software, o que poderia ter um impacto Desempenho. Em seguida, você configurar um dispositivo de loopback para o arquivo MBR: Vamos supor que o dispositivo resultante é / dev / loop0. Porque nós já não teríamos usado outros loopbacks. O próximo passo é criar a imagem de disco MBR / dev / hdaN usando o RAID de software: O resultado / dev / md0 é o que você usará como uma imagem de disco raw QEMU (não se esqueça de definir as permissões para que o emulador possa acessá-lo ). A última etapa (e um tanto complicada) é definir a configuração do disco (geometria do disco e tabela de partições) para que o ponto de início da partição primária no MBR corresponda ao de / dev / hda N dentro de / dev / md0 (um deslocamento de exatamente 16 512 16384 bytes neste exemplo). Faça isso usando o fdisk na máquina host, não no emulador: a rotina de detecção de disco bruta padrão do QEMU geralmente resulta em offsets não-kilobyte-roundable (como 31.5 KB, como na seção anterior) que não podem ser gerenciados pelo software Código RAID. Assim, a partir do anfitrião: Pressione X para entrar no menu especialista. Defina o número de setores por trilha para que o tamanho de um cilindro corresponda ao tamanho do arquivo MBR. Para duas cabeças e um tamanho de setor de 512, o número de setores por faixa deve ser 16, portanto, obtemos cilindros de tamanho 2x16x51216k. Agora, pressione R para retornar ao menu principal. Pressione P e verifique se o tamanho do cilindro é agora 16k. Agora, crie uma única partição primária correspondente a / dev / hda N. Deve começar no cilindro 2 e terminar no final do disco (note que o número de cilindros agora difere do que era quando você digitou o fdisk. Finalmente, escreva o resultado para o arquivo: você está pronto. Você agora tem uma partição Você pode montar diretamente do seu host, bem como parte de uma imagem de disco QEMU: Você pode, com certeza, configurar com segurança qualquer bootloader nesta imagem de disco usando QEMU, desde que a partição original / dev / hda N contenha as ferramentas necessárias. Razão: As topologias de rede (seções Redes somente de host, redes internas e informações espalhadas em outras seções) não devem ser descritas ao lado das várias implementações de interfaces virtuais, como a rede em modo usuário. O desempenho da rede virtual deve ser melhor com dispositivos de toque e pontes do que com a rede de modo de usuário ou vde porque os dispositivos de ponta e pontes são implementados no kernel. Além disso, o desempenho de rede pode ser melhorado através da atribuição de máquinas virtuais um Dispositivo de rede virtio em vez da emulação padrão de uma NIC e1000. Consulte Instalando drivers virtio para obter mais informações. Preenchimento de endereço de nível de link Ao fornecer o argumento - net nic a QEMU, por padrão, atribuirá uma máquina virtual a uma interface de rede com o endereço de link 52: 54: 00: 12: 34: 56. No entanto, ao usar a rede em ponte com várias máquinas virtuais, é essencial que cada máquina virtual tenha um endereço de nível de link (MAC) exclusivo no lado da máquina virtual do dispositivo de toque. Caso contrário, a ponte não funcionará corretamente, porque ele receberá pacotes de várias fontes que tenham o mesmo endereço de nível de link. Esse problema ocorre mesmo se os próprios dispositivos de toque têm endereços de nível de link exclusivo porque o endereço de nível de link de origem não é reescrito como pacotes passam pelo dispositivo de toque. Certifique-se de que cada máquina virtual tem um único endereço de nível de ligação, mas deve sempre iniciar com 52:54. Use a opção a seguir, substitua X por um dígito hexadecimal arbitrário: A geração de endereços de nível de link exclusivos pode ser feita de várias maneiras: Especificar manualmente o endereço de nível de link exclusivo para cada NIC. O benefício é que o servidor DHCP irá atribuir o mesmo endereço IP cada vez que a máquina virtual é executada, mas é inutilizável para grande número de máquinas virtuais. Gerar endereço de nível de link aleatório cada vez que a máquina virtual é executada. Praticamente zero probabilidade de colisões, mas a desvantagem é que o servidor DHCP atribuirá um endereço IP diferente cada vez. Você pode usar o seguinte comando em um script para gerar um endereço de nível de link aleatório em uma variável de macaddr: Use o seguinte script qemu-mac-hasher. py para gerar o endereço de nível de link a partir do nome da máquina virtual usando uma função de hash. Dado que os nomes das máquinas virtuais são únicos, este método combina os benefícios dos métodos acima mencionados: gera o mesmo endereço de nível de link cada vez que o script é executado, mas preserva a probabilidade praticamente nula de colisões. Em um script, você pode usar, por exemplo: Rede de modo de usuário Por padrão, sem quaisquer argumentos-netdev, QEMU usará rede em modo usuário com um servidor DHCP embutido. As máquinas virtuais receberão um endereço IP quando executarem o cliente DHCP e poderão acessar a rede de hosts físicos por meio do IP masquerading feito pelo QEMU. Aviso: Isso só funciona com os protocolos TCP e UDP, assim ICMP, incluindo ping. não funciona. Não use ping para testar a conectividade de rede. Essa configuração padrão permite que as máquinas virtuais acessem facilmente a Internet, desde que o host esteja conectado a ela, mas as máquinas virtuais não estarão diretamente visíveis na rede externa nem as máquinas virtuais poderão conversar entre si se você iniciar Mais de um concorrentemente. A rede em modo usuário QEMUs pode oferecer mais recursos, como servidores TFTP ou SMB internos, redirecionamento de portas de host para o convidado (por exemplo, para permitir conexões SSH para o convidado) ou anexar convidados a VLANs para que eles possam conversar entre si. Consulte a documentação do QEMU no sinalizador - net user para obter mais detalhes. No entanto, a rede em modo de utilizador tem limitações tanto no utilitário como no desempenho. Configurações de rede mais avançadas exigem o uso de dispositivos de toque ou outros métodos. Toque em rede com QEMU Os dispositivos de toque são um recurso de kernel do Linux que permite criar interfaces de rede virtual que aparecem como interfaces de rede reais. Pacotes enviados para uma interface de toque são entregues a um programa de espaço de usuários, como QEMU, que se vinculou à interface. O QEMU pode usar a rede de derivação para uma máquina virtual para que os pacotes enviados para a interface de toque sejam enviados para a máquina virtual e aparecem como provenientes de uma interface de rede (geralmente uma interface Ethernet) na máquina virtual. Por outro lado, tudo o que a máquina virtual envia através de sua interface de rede aparecerá na interface de toque. Os dispositivos de toque são suportados pelos controladores de bridge do Linux, pelo que é possível juntar vários dispositivos de toque entre si e possivelmente com outras interfaces de anfitrião, tais como eth0. Isto é desejável se você quiser que suas máquinas virtuais possam conversar entre si, ou se você quiser que outras máquinas em sua LAN possam falar com as máquinas virtuais. Aviso: Se você conectar o dispositivo e algumas interfaces de host, como eth0. Suas máquinas virtuais aparecerão diretamente na rede externa, o que os expõe a possíveis ataques. Dependendo de quais recursos suas máquinas virtuais têm acesso, você pode precisar tomar todas as precauções que você normalmente tomaria na proteção de um computador para proteger suas máquinas virtuais. Se o risco é muito grande, as máquinas virtuais têm poucos recursos ou você configurar várias máquinas virtuais, uma solução melhor pode ser usar rede host-only e configurar NAT. Neste caso, você precisa apenas de um firewall no host em vez de vários firewalls para cada convidado. Conforme indicado na seção de rede do modo de usuário, os dispositivos de toque oferecem maior desempenho de rede do que o modo de usuário. Se o SO convidado suporta virtio driver de rede, então o desempenho de rede será aumentado consideravelmente também. Supondo que o uso do dispositivo tap0, que o driver virtio é usado no convidado, e que nenhum script é usado para ajudar a iniciar / parar a rede, a seguir é parte do comando qemu um deve ver: Mas se já estiver usando um dispositivo de toque com Virtio networking driver, pode-se até mesmo aumentar o desempenho de rede, permitindo vhost, como: Rede de rede somente de host Se a ponte é dado um endereço IP e tráfego destinado para ele é permitido, mas nenhuma interface real (por exemplo, eth0) está conectado à ponte , As máquinas virtuais poderão conversar entre si e com o sistema host. No entanto, eles não poderão falar com nada na rede externa, desde que você não configure o IP masquerading no host físico. Essa configuração é chamada de rede somente de host por outro software de virtualização, como o VirtualBox. Dica: Se você quiser configurar o IP masquerading, ex. NAT para máquinas virtuais, consulte a página de compartilhamento de InternetEnable NAT. Você pode desejar ter um servidor DHCP executando na interface de ponte para atender a rede virtual. Por exemplo, para usar a sub-rede 172.20.0.1/16 com dnsmasq como servidor DHCP: Rede interna Se você não atribuir um endereço IP à ponte e adicionar uma regra iptables para descartar todo o tráfego para a ponte na cadeia INPUT, As máquinas virtuais poderão conversar entre si, mas não com o host físico ou com a rede externa. Essa configuração é chamada de rede interna por outro software de virtualização, como o VirtualBox. Você precisará atribuir endereços IP estáticos para as máquinas virtuais ou executar um servidor DHCP em um deles. Por padrão, o iptables solta pacotes na rede de bridge. Você pode precisar usar essa regra iptables para permitir pacotes em uma rede em ponte: Bridged networking usando qemu-bridge-helper Este método não requer um script de inicialização e prontamente acomoda múltiplas conexões e várias pontes. Ele usa o binário / usr / lib / qemu / qemu-bridge-helper, que permite criar dispositivos de toque em uma ponte existente. Dica: Consulte Ponte de rede para obter informações sobre como criar bridge. Primeiro, crie um arquivo de configuração contendo os nomes de todas as pontes a serem usadas pelo QEMU: Agora inicie a VM. O uso mais básico seria: Com vários toques, o uso mais básico requer a especificação da VLAN para todas as NICs adicionais: Criando ponte manualmente Razão: Esta seção precisa de limpeza séria e pode conter informações desatualizadas. (Discutir em Discussão: QEMU) A seguir, descreve como conectar uma máquina virtual a uma interface de host, como eth0. Que é provavelmente a configuração mais comum. This configuration makes it appear that the virtual machine is located directly on the external network, on the same Ethernet segment as the physical host machine. We will replace the normal Ethernet adapter with a bridge adapter and bind the normal Ethernet adapter to it. Install bridge-utils. which provides brctl to manipulate bridges. Enable IPv4 forwarding: To make the change permanent, change net. ipv4.ipforward 0 to net. ipv4.ipforward 1 in /etc/sysctl. d/99-sysctl. conf. Load the tun module and configure it to be loaded on boot. See Kernel modules for details. Now create the bridge. See Bridge with netctl for details. Remember to name your bridge as br0. or change the scripts below to your bridges name. Create the script that QEMU uses to bring up the tap adapter with root:kvm 750 permissions: Create the script that QEMU uses to bring down the tap adapter in /etc/qemu-ifdown with root:kvm 750 permissions: Use visudo to add the following to your sudoers file: You launch QEMU using the following run-qemu script: Then to launch a VM, do something like this It is recommended for performance and security reasons to disable the firewall on the bridge : Run sysctl - p /etc/sysctl. d/10-disable-firewall-on-bridge. conf to apply the changes immediately. See the libvirt wiki and Fedora bug 512206. If you get errors by sysctl during boot about non-existing files, make the bridge module load at boot. See Kernel modulesAutomatic module handling. Alternatively, you can configure iptables to allow all traffic to be forwarded across the bridge by adding a rule like this: Network sharing between physical device and a Tap device through iptables Notes: Duplication, not specific to QEMU. (Discuss in Talk:QEMU ) Bridged networking works fine between a wired interface (Eg. eth0), and it is easy to setup. However if the host gets connected to the network through a wireless device, then bridging is not possible. One way to overcome that is to setup a tap device with a static IP, making linux automatically handle the routing for it, and then forward traffic between the tap interface and the device connected to the network through iptables rules. There you can find what is needed to share the network between devices, included tap and tun ones. The following just hints further on some of the host configurations required. As indicated in the reference above, the client needs to be configured for a static IP, using the IP assigned to the tap interface as the gateway. The caveat is that the DNS servers on the client might need to be manually edited if they change when changing from one host device connected to the network to another. To allow IP forwarding on every boot, one need to add the following lines to sysctl configuration file inside /etc/sysctl. d: The iptables rules can look like: The prior supposes there are 3 devices connected to the network sharing traffic with one internal device, where for example: The prior shows a forwarding that would allow sharing wired and wireless connections with the tap device. The forwarding rules shown are stateless, and for pure forwarding. One could think of restricting specific traffic, putting a firewall in place to protect the guest and others. However those would decrease the networking performance, while a simple bridge does not include any of that. Bonus: Whether the connection is wired or wireless, if one gets connected through VPN to a remote site with a tun device, supposing the tun device opened for that connection is tun0, and the prior iptables rules are applied, then the remote connection gets also shared with the guest. This avoids the need for the guest to also open a VPN connection. Again, as the guest networking needs to be static, then if connecting the host remotely this way, one most probably will need to edit the DNS servers on the guest. Networking with VDE2 Reason: This section needs serious cleanup and may contain out-of-date information. (Discuss in Talk:QEMU ) What is VDE VDE stands for Virtual Distributed Ethernet. It started as an enhancement of uml switch. It is a toolbox to manage virtual networks. The idea is to create virtual switches, which are basically sockets, and to plug both physical and virtual machines in them. The configuration we show here is quite simple However, VDE is much more powerful than this, it can plug virtual switches together, run them on different hosts and monitor the traffic in the switches. You are invited to read the documentation of the project. The advantage of this method is you do not have to add sudo privileges to your users. Regular users should not be allowed to run modprobe. Basics In our config, we use tun/tap to create a virtual interface on my host. Load the tun module (see Kernel modules for details): Now create the virtual switch: This line creates the switch, creates tap0. plugs it, and allows the users of the group users to use it. The interface is plugged in but not configured yet. To configure it, run this command: Now, you just have to run KVM with these - net options as a normal user: Configure networking for your guest as you would do in a physical network. Tip: You might want to set up NAT on tap device to access the internet from the virtual machine. See Internet sharingEnable NAT for more information. Startup scripts Example of main script starting VDE: Example of systemd service using the above script: Change permissions for qemu-network-env to be executable You can start qemu-network-env. service as usual. Alternative method If the above method does not work or you do not want to mess with kernel configs, TUN, dnsmasq, and iptables you can do the following for the same result. Then, to start the VM with a connection to the network of the host: VDE2 Bridge Based on quickhowto: qemu networking using vde, tun/tap, and bridge graphic. Any virtual machine connected to vde is externally exposed. For example, each virtual machine can receive DHCP configuration directly from your ADSL router. Basics Remember that you need tun module and bridge-utils package. Create the vde2/tap device: And configure bridge interface: Startup scripts All devices must be set up. And only the bridge needs an IP address. For physical devices on the bridge (e. g. eth0 ), this can be done with netctl using a custom Ethernet profile with: The following custom systemd service can be used to create and activate a VDE2 tap interface for use in the users user group. Graphics QEMU can use the following different graphic outputs: std. qxl. vmware. virtio. cirrus and none. std With - vga std you can get a resolution of up to 2560 x 1600 pixels without requiring guest drivers. This is the default since QEMU 2.2. qxl QXL is a paravirtual graphics driver with 2D support. To use it, pass the - vga qxl option and install drivers in the guest. You may want to use SPICE for improved graphical performance when using QXL. On Linux guests, the qxl and bochsdrm kernel modules must be loaded in order to gain a decent performance. SPICE The SPICE project aims to provide a complete open source solution for remote access to virtual machines in a seamless way. SPICE can only be used when using QXL as the graphical output. The following is example of booting with SPICE as the remote desktop protocol: Connect to the guest by using a SPICE client. At the moment spice-gtk3 is recommended, however other clients. including other platforms, are available: Using Unix sockets instead of TCP ports does not involve using network stack on the host system, so it is reportedly better for performance. Example: For improved support for multiple monitors, clipboard sharing, etc. the following packages should be installed on the guest: spice-vdagent AUR . Spice agent xorg client that enables copy and paste between client and X-session and more xf86-video-qxl AUR xf86-video-qxl-git AUR . Xorg X11 qxl video driver For other operating systems, see the Guest section on SPICE-Space download page. vmware Although it is a bit buggy, it performs better than std and cirrus. Install the VMware drivers xf86-video-vmware and xf86-input-vmmouse for Arch Linux guests. virtio virtio-vga / virtio-gpu is a paravirtual 3D graphics driver based on virgl. Currently a work in progress, supporting only very recent (gt 4.4) Linux guests with mesa (gt11.2) compiled with the option --with-gallium-driversvirgl. To enable 3D acceleration on the guest system select this vga with - vga virtio and enable the opengl context in the display device with - display sdl, glon or - display gtk, glon for the sdl and gtk display output respectively. Successful configuration can be confirmed looking at the kernel log in the guest: As of September 2016, support for the spice protocol is under development and can be tested installing the development release of spice (gt 0.13.2). cirrus The cirrus graphical adapter was the default before 2.2. It should not be used on modern systems. none This is like a PC that has no VGA card at all. You would not even be able to access it with the - vnc option. Also, this is different from the - nographic option which lets QEMU emulate a VGA card, but disables the SDL display. vnc Given that you used the - nographic option, you can add the - vnc display option to have QEMU listen on display and redirect the VGA display to the VNC session. There is an example of this in the Starting QEMU virtual machines on boot sections example configs. When using VNC, you might experience keyboard problems described (in gory details) here. The solution is not to use the - k option on QEMU, and to use gvncviewer from gtk-vnc. See also this message posted on libvirts mailing list. Installing virtio drivers QEMU offers guests the ability to use paravirtualized block and network devices using the virtio drivers, which provide better performance and lower overhead. A virtio block device requires the option - drive instead of the simple - hd plus ifvirtio : Note: - boot orderc is absolutely necessary when you want to boot from it. There is no auto-detection as with - hd . Almost the same goes for the network: Note: This will only work if the guest machine has drivers for virtio devices. Linux does, and the required drivers are included in Arch Linux, but there is no guarantee that virtio devices will work with other operating systems. Preparing an (Arch) Linux guest To use virtio devices after an Arch Linux guest has been installed, the following modules must be loaded in the guest: virtio. virtiopci. virtioblk. virtionet. and virtioring. For 32-bit guests, the specific virtio module is not necessary. If you want to boot from a virtio disk, the initial ramdisk must contain the necessary modules. By default, this is handled by mkinitcpio s autodetect hook. Otherwise use the MODULES array in /etc/mkinitcpio. conf to include the necessary modules and rebuild the initial ramdisk. Virtio disks are recognized with the prefix v (e. g. v da. v db. etc.) therefore, changes must be made in at least /etc/fstab and /boot/grub/grub. cfg when booting from a virtio disk. Tip: When referencing disks by UUID in both /etc/fstab and bootloader, nothing has to be done. Further information on paravirtualization with KVM can be found here. You might also want to install qemu-guest-agent to implement support for QMP commands that will enhance the hypervisor management capabilities. After installing the package you can enable and start the qemu-ga. service. Preparing a Windows guest Note: The only (reliable) way to upgrade a Windows 8.1 guest to Windows 10 seems to be to temporarily choose cpu core2duo, nx for the install 2. After the install, you may revert to other cpu settings (8/8/2015). Block device drivers New Install of Windows Windows does not come with the virtio drivers. Therefore, you will need to load them during installation. There are basically two ways to do this: via Floppy Disk or via ISO files. Both images can be downloaded from the Fedora repository. The floppy disk option is difficult because you will need to press F6 (Shift-F6 on newer Windows) at the very beginning of powering on the QEMU. This is difficult since you need time to connect your VNC console window. You can attempt to add a delay to the boot sequence. See man qemu-system for more details about applying a delay at boot. The ISO option to load drivers is the preferred way, but it is available only on Windows Vista and Windows Server 2008 and later. The procedure is to load the image with virtio drivers in an additional cdrom device along with the primary disk device and Windows installer: During the installation, the Windows installer will ask you for your Product key and perform some additional checks. When it gets to the Where do you want to install Windows screen, it will give a warning that no disks are found. Follow the example instructions below (based on Windows Server 2012 R2 with Update). Select the option Load Drivers . Uncheck the box for Hide drivers that arent compatible with this computers hardware. Click the Browse button and open the CDROM for the virtio iso, usually named virtio-win-XX. Now browse to E:viostoryour-osamd64. select it, and press OK. Click Next You should now see your virtio disk(s) listed here, ready to be selected, formatted and installed to. Change Existing Windows VM to use virtio Modifying an existing Windows guest for booting from virtio disk is a bit tricky. You can download the virtio disk driver from the Fedora repository. Now you need to create a new disk image, which fill force Windows to search for the driver. For example: Run the original Windows guest (with the boot disk still in IDE mode) with the fake disk (in virtio mode) and a CD-ROM with the driver. Windows will detect the fake disk and try to find a driver for it. If it fails, go to the Device Manager . locate the SCSI drive with an exclamation mark icon (should be open), click Update driver and select the virtual CD-ROM. Do not forget to select the checkbox which says to search for directories recursively. When the installation is successful, you can turn off the virtual machine and launch it again, now with the boot disk attached in virtio mode: Note: If you encounter the Blue Screen of Death, make sure you did not forget the - m parameter, and that you do not boot with virtio instead of ide for the system drive before drivers are installed. Network drivers Installing virtio network drivers is a bit easier, simply add the - net argument as explained above. Windows will detect the network adapter and try to find a driver for it. If it fails, go to the Device Manager . locate the network adapter with an exclamation mark icon (should be open), click Update driver and select the virtual CD-ROM. Do not forget to select the checkbox which says to search for directories recursively. Preparing a FreeBSD guest Install the emulators/virtio-kmod port if you are using FreeBSD 8.3 or later up until 10.0-CURRENT where they are included into the kernel. After installation, add the following to your /boot/loader. conf file: Then modify your /etc/fstab by doing the following: And verify that /etc/fstab is consistent. If anything goes wrong, just boot into a rescue CD and copy /etc/fstab. bak back to /etc/fstab. Tips and tricks Starting QEMU virtual machines on boot With libvirt If a virtual machine is set up with libvirt. it can be configured through the virt-manager GUI to start at host boot by going to the Boot Options for the virtual machine and selecting Start virtual machine on host boot up. Custom script To run QEMU VMs on boot, you can use following systemd unit and config. Note: According to systemd. service(5) and systemd. kill(5) man pages it is necessary to use the KillModenone option. Otherwise the main qemu process will be killed immediately after the ExecStop command quits (it simply echoes one string) and your quest system will not be able to shutdown correctly. Then create per-VM configuration files, named /etc/conf. d/qemu. d/ vmname . with the following variables set: type QEMU binary to call. If specified, will be prepended with /usr/bin/qemu - and that binary will be used to start the VM. I. e. you can boot e. g. qemu-system-arm images with typesystem-arm. args QEMU command line to start with. Will always be prepended with - name - nographic. haltcmd Command to shut down a VM safely. I am using - monitor telnet. and power off my VMs via ACPI by sending systempowerdown to monitor. You can use SSH or some other ways. To set which virtual machines will start on boot-up, enable the qemu vmname. service systemd unit. Mouse integration To prevent the mouse from being grabbed when clicking on the guest operating systems window, add the option - usbdevice tablet. This means QEMU is able to report the mouse position without having to grab the mouse. This also overrides PS/2 mouse emulation when activated. For example: Pass-through host USB device To access physical USB device connected to host from VM, you can use the option: - usbdevice host: vendorid : productid . You can find vendorid and productid of your device with lsusb command. Since the default I440FX chipset emulated by qemu feature a single UHCI controller (USB 1), the - usbdevice option will try to attach your physical device to it. In some cases this may cause issues with newer devices. A possible solution is to emulate the ICH9 chipset, which offer an EHCI controller supporting up to 12 devices, using the option - machine typeq35. A less invasive solution is to emulate an EHCI (USB 2) or XHCI (USB 3) controller with the option - device usb-ehci, idehci or - device nec-usb-xhci, idxhci respectively and then attach your physical device to it with the option - device usb-host. as follows: You can also add the. port ltngt setting to the previous option to specify in which physical port of the virtual controller you want to attach your device, useful in the case you want to add multiple usb devices to the VM. Note: If you encounter permission errors when running QEMU, see UdevWriting udev rules for information on how to set permissions of the device. Enabling KSM Kernel Samepage Merging (KSM) is a feature of the Linux kernel that allows for an application to register with the kernel to have its pages merged with other processes that also register to have their pages merged. The KSM mechanism allows for guest virtual machines to share pages with each other. In an environment where many of the guest operating systems are similar, this can result in significant memory savings. To enable KSM, simply run If KSM is running, and there are pages to be merged (i. e. at least two similar VMs are running), then /sys/kernel/mm/ksm/pagesshared should be non-zero. See www. kernel. org/doc/Documentation/vm/ksm. txt for more information. Tip: An easy way to see how well KSM is performing is to simply print the contents of all the files in that directory: Multi-monitor support The Linux QXL driver supports four heads (virtual screens) by default. This can be changed via the qxl. headsN kernel parameter. The default VGA memory size for QXL devices is 16M (VRAM size is 64M). This is not sufficient if you would like to enable two 1920x1200 monitors since that requires 2 1920 4 (color depth) 1200 17.6 MiB VGA memory. This can be changed by replacing - vga qxl by - vga none - device qxl-vga, vgamemmb32. If you ever increase vgamemmb beyond 64M, then you also have to increase the vramsizemb option. Copy and paste To have copy and paste between the host and the guest you need to enable the spice agent communication channel. It requires to add a virtio-serial device to the guest, and open a port for the spice vdagent. It is also required to install the spice vdagent in guest ( spice-vdagent AUR for Arch guests, Windows guest tools for Windows guests). Make sure the agent is running (and for future, started automatically). Start QEMU with the following options: The - device virtio-serial-pci option adds the virtio-serial device, - device virtserialport, chardevspicechannel0,namecom. redhat. spice.0 opens a port for spice vdagent in that device and - chardev spicevmc, idspicechannel0,namevdagent adds a spicevmc chardev for that port. It is important that the chardev option of the virtserialport device matches the id option given to the chardev option ( spicechannel0 in this example). It is also important that the port name is com. redhat. spice.0. because that is the namespace where vdagent is looking for in the guest. And finally, specify namevdagent so that spice knows what this channel is for. Windows-specific notes QEMU can run any version of Windows from Windows 95 through Windows 10. It is possible to run Windows PE in QEMU. Fast startup For Windows 8 (or later) guests it is better to disable Fast Startup from the Power Options of the Control Panel, as it causes the guest to hang during every other boot. Fast Startup may also need to be disabled for changes to the - smp option to be properly applied. Remote Desktop Protocol If you use a MS Windows guest, you might want to use RDP to connect to your guest VM. If you are using a VLAN or are not in the same network as the guest, use: Then connect with either rdesktop or freerdp to the guest. For example: Troubleshooting Mouse cursor is jittery or erratic If the cursor jumps around the screen uncontrollably, entering this on the terminal before starting QEMU might help: If this helps, you can add this to your No visible Cursor Add - show-cursor to QEMUs options to see a mouse cursor. Keyboard seems broken or the arrow keys do not work Should you find that some of your keys do not work or press the wrong key (in particular, the arrow keys), you likely need to specify your keyboard layout as an option. The keyboard layouts can be found in /usr/share/qemu/keymaps. Virtual machine runs too slowly There are a number of techniques that you can use to improve the performance if your virtual machine. For example: Use the - cpu host option to make QEMU emulate the hosts exact CPU. If you do not do this, it may be trying to emulate a more generic CPU. If the host machine has multiple CPUs, assign the guest more CPUs using the - smp option. Make sure you have assigned the virtual machine enough memory. By default, QEMU only assigns 128 MiB of memory to each virtual machine. Use the - m option to assign more memory. For example, - m 1024 runs a virtual machine with 1024 MiB of memory. Use KVM if possible: add - machine typepc, accelkvm to the QEMU start command you use. If supported by drivers in the guest operating system, use virtio for network and/or block devices. For example: Use TAP devices instead of user-mode networking. See Tap networking with QEMU . If the guest OS is doing heavy writing to its disk, you may benefit from certain mount options on the hosts file system. For example, you can mount an ext4 file system with the option barrier0. You should read the documentation for any options that you change because sometimes performance-enhancing options for file systems come at the cost of data integrity. If you have a raw disk image, you may want to disable the cache: Use the native Linux AIO: If you are running multiple virtual machines concurrently that all have the same operating system installed, you can save memory by enabling kernel same-page merging : In some cases, memory can be reclaimed from running virtual machines by running a memory ballooning driver in the guest operating system and launching QEMU with the - balloon virtio option. Guest display stretches on window resize To restore default window size, press CtrlAltu. ioctl(KVMCREATEVM) failed: 16 Device or resource busy If an error message like this is printed when starting QEMU with - enable-kvm option: that means another hypervisor is currently running. It is not recommended or possible to run several hypervisors in parallel. libgfapi error message The error message displayed at startup: is not a problem, it just means that you are lacking the optional GlusterFS dependency. Kernel panic on LIVE-environments If you start a live-environment (or better: booting a system) you may encounter this: or some other boot hindering process (e. g. cannot unpack initramfs, cant start service foo). Try starting the VM with the - m VALUE switch and an appropriate amount of RAM, if the ram is to low you will probably encounter similar issues as above/without the memory-switch. See alsoQEMU/Images Once QEMU has been installed, it should be ready to run a guest OS from a disk image. This image is a file that represents the data on a hard disk. From the perspective of the guest OS, it actually is a hard disk, and it can create its own filesystem on the virtual disk. You can download a few guest OS images from the QEMU website. including a simple 8 MB image of a Linux distro (which is meant primarily for testing note that it lacks the e1000 driver and therefore cannot do networking out-of-the-box). To run it, download and unzip the image in a folder and run the QEMU command. When you do not have the plain command qemu try to run: Replace linux-0.2.img with the name of your guest OS image file. If it has a GUI and you want to use your mouse with it, double-click on the window and QEMU will grab your mouse. To make QEMU release your mouse again, hold down the Control and Alt keys simultaneously, then let go - your mouse will be released back to X. Aurlien Jarno of Debian has prepared a number of pre-packaged Debian QEMU images for several architectures, including ARM, Sparc, PowerPC, x8664, and i386. They can be found at people. debian. org/ For some of the test kernels that you get, for example, the Sparc test image, you might get the error No NFS Server available giving up or some other message about needing to insert a Root Floppy or even a message specifying to fix the root option. If so then specify root/dev/ram as an addition kernel command line option. This will then cause the test system to work. This is specifically true for the Sparc test files available from wiki. qemu. org/Testing. but probably for some of the others as well. If you are using the manager program for windows then just add the root/dev/ram/ in the advanced tab. Also turn off video and sound and if using qemu-system-sparcw. exe then change the filename to qemu-system-sparc. exe because some renamed it. Contents QEMU supports several image types. The native and most flexible type is qcow2 . which supports copy on write. encryption, compression, and VM snapshots. QEMU currently can use these image types or formats: raw (default) the raw format is a plain binary image of the disc image, and is very portable. On filesystems that support sparse files. images in this format only use the space actually used by the data recorded in them. cloop Compressed Loop format, mainly used for reading Knoppix and similar live CD image formats cow copy-on-write format, supported for historical reasons only and not available to QEMU on Windows qcow the old QEMU copy-on-write format, supported for historical reasons and superseded by qcow2 qcow2 QEMU copy-on-write format with a range of special features, including the ability to take multiple snapshots, smaller images on filesystems that dont support sparse files, optional AES encryption, and optional zlib compression vmdk VMware 3 amp 4, or 6 image format, for exchanging images with that product vdi VirtualBox 1.1 compatible image format, for exchanging images with VirtualBox. vhdx Hyper-V compatible image format, for exchanging images with Hyper-V 2012 or later. vpc Hyper-V legacy image format, for exchanging images with Virtual PC / Virtual Server / Hyper-V 2008. To set up your own guest OS image, you first need to create a blank disc image. QEMU has the qemu-img command for creating and manipulating disc images, and supports a variety of formats. If you dont tell it what format to use, it will use raw files. The native format for QEMU is qcow2, and this format offers some flexibility. Here well create a 3 GB qcow2 image to install Windows XP on: The easiest way to install a guest OS is to create an ISO image of a boot CD/DVD and tell QEMU to boot off it. Many free operating systems can be downloaded from the Internet as bootable ISO images, and you can use them directly without having to burn them to disc. Here well boot off an ISO image of a properly licensed Windows XP boot disc. Well also give it 256 MB of RAM, but we wont use the kqemu kernel module just yet because it causes problems during Windows XP installation. To boot from a real CD or DVD, tell QEMU where to find it. On Linux systems, you can usually use a logical device name like /dev/cdrom or /dev/dvd. or the physical name of the device, e. g. /dev/sr0 QEMU will boot from the ISO image or CD/DVD and run the install program. If you have two screens, move the QEMU screen off to the spare one where you can keep an eye on the installer, but get on with something else - it will take a while Once the guest OS has installed successfully, you can shutdown the guest OS (e. g. in Windows XP, click on Start and then Shutdown). Once it has shutdown, start QEMU up with the kqemu kernel module to give it a little more speed. If you are running an x86-64 Linux (i. e. 64-bit), you will need to run the x86-64 version of QEMU to be able to utilise kqemu: Using multiple images Edit QEMU can utilise up to four image files to present multiple virtual drives to the guest system. This can be quite useful, as in the following examples: a pagefile or swapfile virtual disc that can be shared between QEMU guests a common data drive where all data is stored, accessible from each QEMU guest but isolated from the host giving additional space to a QEMU guest without reconfiguring the primary image separating competing I/O operations onto different physical drive spindles by placing the separate QEMU images on different physical drives emulating a multi-drive physical environment for testing / learning Bear in mind that only one instance of QEMU may access an image at a time - shared doesnt mean shared simultaneously To use additional images in QEMU, specify them on the command line with options - hda, - hdb, - hdc, - hdd. NB: QEMU doesnt support both - hdc and - cdrom at the same time, as they both represent the first device on the second IDE channel. The cow part of qcow2 is an acronym for copy on write. a neat little trick that allows you to set up an image once and use it many times without changing it. This is ideal for developing and testing software, which generally requires a known stable environment to start off with. You can create your known stable environment in one image, and then create several disposable copy-on-write images to work in. To start a new disposable environment based on a known good image, invoke the qemu-img command with the backingfile option and tell it what image to base its copy on. When you run QEMU using the disposable environment, all writes to the virtual disc will go to this disposable image, not the base copy. NB: 1) dont forget to copy any important data out of the disposable environment before deleting it. When developing and testing software in copy-on-write virtual environments, it is a good idea to use version control software like Subversion or CVS on a server external to your virtual environment. Not only is it easy to keep copies of your work outside your virtual environment, it is also very easy to set up a new virtual environment from version control. 2) backingfile image must be set as read-only on VMs, that will be using it directly. Otherwise, other images, based on this backingfile image will be corrupted, if there is some change have been made to the backingfile image. Mounting an image on the host Edit Sometimes it is helpful to be able to mount a drive image under the host system. For example, if the guest doesnt have network support, the only way to transfer files into and out of the guest will be by the storage devices it can address. Linux and other Unix-like hosts can mount images created with the raw format type using a loopback device. From a root login (or using sudo), mount a loopback with offset. To determine the correct offset you can run and the offset you need is the start of a partition multiplied by sector size. For example if start is 128 and sector size is 512 then the offset is 65536. For example, to copy some files across to a FreeDOS hard drive image: NB: never mount a QEMU image while QEMU is using it (unless - snapshot is used), or you are likely to corrupt the filesystem on the image. Note: if you have an image without partitions you should omit the, offset32256 part. This is for instance the case if you want to mount linux-0.2.img (which can be found at the qemu web site at the time of writing). For other types of qemu images, you can use qemu-nbd Using fdisk you can get information regarding the different partitions in nbd0. LVM type partitions cannot be mounted using mount. In such a case the image could be mounted with: Replace ltLogicalVolumeNamegt with the name of the logical volume present in the volume group. Finally, after the usage its important to unmount the image and reverse other steps (depending on how the image was mounted): nbd stands for Network Block Device. Here were using them locally, but one can also export the image for other hosts to use/mount. See qemu-nbd(8), nbd-client(8) for details. The same can be done for raw images, but its a lot less efficient than the loop method described above. Another alternative for vmdk and raw images is to use vdfuse (forums. virtualbox. org/viewtopicf26ampt33355 ) which allows to access any image supported by VirtualBox. Copying an image to a physical device Edit It may be desired to copy a diskimage to a physical device. An example may be if building a cluster, it might be easier to get everything ready in qemu, then write the final diskimage to all of the hard drives. Of course your image will need to contain all of required configuration and drivers for the new system to boot properly. The diskimage will need to be in raw format. Then you just dd it onto the hard drive. Or, let qemu-img directly write onto the drive in one command: Of course you need to be careful that you write it to the correct drive The qemu-img program can tell you about the format, virtual size, physical size, and snapshots inside an image. Converting image formats Edit The qemu-img program can be used to convert images from one format to another, or add compression or encryption to an image. Specify the source and target files for the image, and select from the following options: - f fmt optional, specify the format of the input file (QEMU can usually detect it) - O fmt specify the format of the output file - e use encryption in the output file (you will be prompted for a password) - c use compression in the output file (cant be used with encryption) -6 when converting to vmdk (VMware) format, make it compatible with VMware 6 Exchanging images with VirtualBox Edit qemu also supports the vdi format, so you can convert in both ways: qemu can use the vdi format for booting as well as a base image because VirtualBox also supports this type of image, called there differencing image, a single (read-only) base copy could be shared simultaneously. In any case, you may use the raw format (or an nbd device): To convert a QEMU image for use with VirtualBox. first convert it to raw format, then use VirtualBoxs conversion utility to convert and compact it in its native format. Note that the compact command requires the full path to the VirtualBox image, not just the filename. Alternatively, you may use qemu-nbd to make the image available as raw as an nbd device, which VBoxManage can then convert. To convert a VDI back to raw, one may use VBoxManage again: To use a VDI image from KVM without converting it, vdfuse may be used again. Download Latest Source Code QEMU is developed using git. The main tree is located at git. qemu. org/qemu. git. The latest development happens on the master branch. The stable tree is located in a stable-X. YY branch where X. YY is the release version. To download the latest development tree, use the following command: and also see instructions on that page for other ways to access the source. Content is available under GNU Free Documentation License 1.2 . QEMU is a trademark of Fabrice Bellard. Hosting generously provided by OSUOSL .
No comments:
Post a Comment