Dual-boot e virtualizar o Windows 8 e o Ubuntu

Question

Windows e Linux de inicialização dupla estão bem documentados, assim como a execução de um dos sistemas operacionais inicializáveis como uma máquina virtual dentro do outro (ex, dual-boot Windows e Ubuntu; no Windows, host Ubuntu em uma VM usando VMWare Workstation / Player / etc).

Estou planejando uma compilação e quero ter o melhor dos dois mundos: ser capaz de inicializar no Windows 8 e executar o Ubuntu em uma VM, depois inicializar na mesma instalação do Ubuntu e executar a mesma instalação do Windows 8 em uma VM, com os dois sistemas compartilhando uma partição para arquivos de projeto, etc. Parece que deveria ser possível.

• Existem algumas ressalvas que tornariam isso impossível / extremamente difícil / instável?
• Há alguma configuração de disco sugerida (duas unidades físicas, etc.)?

ATUALIZAÇÃO:

Encontrei algumas informações sobre como obter o Windows 7 & 8 executando nesta configuração. É bastante hacktastic e há uma boa chance de você abrir sua instalação do Windows, mas no caso de alguém estar mais comprometido com isso do que eu sou:

    

Answer 1

Esta parte é fundamental:

run the same Windows 8 install in a VM

Sim, existem algumas advertências sérias que tornariam isso extremamente difícil e possivelmente instável. Os monitores de máquina virtual (VMMs), como o VirtualBox, o VMware Workstation / Player, o Virtual PC, etc., normalmente apresentam hardware virtualizado diferente do que o sistema atual possui.

Os VMMs baseados em QEMU geralmente apresentam um chipset PIIX3 ao sistema operacional convidado. O VirtualBox oferece uma opção para o PIIX3, ICH9. O VMware Workstation e o VMware Player também emulam um chipset, que seu PC provavelmente não possui.

Nas versões anteriores do Windows, havia um recurso para selecionar Perfis de hardware, que pode permitir que você faça isso com segurança, mas provavelmente não é o uso pretendido para isso. Também não há uma boa maneira de escolher o perfil automaticamente.

Outras características que diferem drasticamente entre seu hardware real e o hardware virtualizado incluem: adaptador de vídeo (quaisquer gráficos acelerados precisarão de um driver para-virtualizado, e isso provavelmente falhará), controlador de disco (você pode ser capaz de extrair este se você tiver o hardware real para ele, como o LSI 1068e, uma placa BusLogic real ou, muito provavelmente, você pode configurar seu controlador de disco para apresentar a interface AHCI SATA e convencer seu VMM a apresentar um controlador de disco AHCI inicializável) (se você tem uma placa Intel, você provavelmente tem um controlador UHCI USB 1.x em vez do OHCI que o VirtualBox apresenta), áudio (SoundBlaster 16 e Ensoniq Audio PCI são hardware geralmente emulado, mas desatualizado), etc.

Fazer isso no Linux não é tão ruim, já que a maioria dos detalhes de configuração de hardware que são apresentados ao SO são escolhidos no momento da inicialização, com exceção de coisas como as regras do udev, então você pode obter uma interface de rede estranha nomes.

O verdadeiro perigo, eu acho, está em ter os drivers paravirtualizados do VMM que executam hiperchamadas fazendo coisas que são indefinidas em uma plataforma real. Se os drivers paravirtualizados supõem cegamente que o VMM está presente sem verificação, é muito provável que o kernel acione uma falha inesperada, o que se traduz em um kernel panic no Linux e um BSoD no Windows (se você não ativar o triplo falha de desligamento primeiro). Quão provável é isso? Na verdade, tive problemas com isso no Linux, com os drivers de vídeo do PV VMware acionando um travamento no Virtual PC.