Estado da VM após 'virsh save'

3

virsh save vm_name memdump e, em seguida, virsh restore memdump restaura uma VM (em execução), tudo bem.

No entanto, uma VM é desligada após virsh save . Estou escrevendo um script de backup e restauração "ao vivo" para VMs KVM, portanto, na parte de backup, obviamente, preciso de uma VM em execução após o backup. Não é um problema fazer virsh restore memdump logo após o backup, mas me parece essencialmente desnecessário - "deveria" ser capaz de pausar uma VM, salvar sua memória em um arquivo e simplesmente retomar / suspender uma VM.

Isso não é realmente um problema com VMs que possuem pouca memória, mas se a VM tiver memória de trabalho considerável, ela prolonga o backup desnecessariamente.

Infelizmente, uma VM é desativada mesmo se eu fizer virsh suspend antes de virsh save .

Existe uma maneira de fazer isso? (isto é, suspender, salvar, suspender)

    
por LetMeSOThat4U 22.03.2015 / 11:25

2 respostas

3

Primeiro, concordo totalmente com @dyasny, é difícil encontrar um caso de uso razoável para 'estado de VM completo (também conhecido como memória)'.

Mas, se você realmente quer 'virsh save vm_name memdump' sem destruir o vm, você pode tentar

virsh snapshot-create-as  ${domain} ${fake_snap} 'save vm while keep running' \
 --no-metadata --atomic --live \
 --memspec  ${path_to_mem_dump_file},snapshot=external

Boa sorte:)

======== Atualizando: (muito longo para postar como resposta) ===============

Oh, talvez esta seja a minha verbosidade 'estado completo da VM' == mem_state + disk_state, enquanto 'mem_state' == 'memória física vm' + 'vm cpu registra' + 'vm estado do dispositivo no hypervisor'.

Por isso, é seguro "virsh save" e "virsh store", já que não há nada a perder,  'salvar / restaurar', assim como 'laptop dormindo', normalmente você terá seu aplicativo continuar em execução depois que você 'restaurar' um vm.

É desastroso se 'mem_state' e 'disk_state' estão fora de sincronia é por isso que 'virsh save' invoca um 'destroy' depois de 'save mem'.

Meu 'virsh save without destroy' é na verdade um 'backup completo da VM', o disk_snapshot é atrasado dentro do qcow2 original. Então você acabou de ver um 'mem_state'. :)

    
por 31.03.2015 / 12:25
2

Se a VM tiver muita memória, salvá-la significa, em qualquer caso, uma grande quantidade de tempo gasto salvando o memstate.

Se não houver um requisito rígido para fazer backup de um estado completo da VM (porque geralmente ele é redundante, você receberá erros ao restaurar devido a diferenças de tempo e pode até levar a uma falha).

Normalmente, as VMs fazem backup da seguinte forma:

  1. Sistemas de arquivos do Quiesce Vm
  2. Tire um instantâneo ao vivo do (s) disco (s) da VM
  3. Backup dos discos e da configuração da VM ( virsh dumpxml VM )
  4. Ao vivo, mescle os discos para que o instantâneo desapareça

Agora, a única parte que pode ser complicada com o kvm é a última parte. É meio que suportado usando blockpull na maioria das distribuições atuais, mas isso não irá mesclar o instantâneo na imagem base, ele fará o oposto - puxe os dados da base para o instantâneo, para que você possa remover a base. O melhor comando é blockcommit , ele vai empurrar os bits alterados do instantâneo para a imagem base, no entanto, ele está disponível apenas nas distribuições de borda de ponta. Espero que chegue ao RHEL 7.1, veremos

    
por 23.03.2015 / 00:59