Mostrando postagens classificadas por relevância para a consulta hypervisor. Ordenar por data Mostrar todas as postagens

DragonflyBSD receberá suporte a Hypervisor do NetBSD

Kamil Rytarowski (CTO da Moritz Systems) informou que a Motriz Systems reservou Code Bounty (que é um meio de financiamento do DragonflyBSD) para trabalhar no port de Hypervisor para o DragonflyBSD tendo como principal desenvolvedor Jaromir Dolecek. Há duas propostas de port de Hypervisor:

nvmm do NetBSD
bhyve do FreeBSD

A Motriz Systems planeja portar o NVMM (NetBSD Virtual Machine Monitor) para o DragonflyBSD. NVMM é uma plataforma hypervisor que fornece suporte a aceleração via hardware. Uma API de virtualização é carregada pela biblioteca libnvmm que permite criar e gerenciar facilmente máquinas virtuais com o NVMM. O pacote Qemu no pkgsrc foi modificado para alavancar a API de virtualização e prover emulação rápida.

Módulo nvmm carregado com Qemu no NetBSD

Muito trabalho já feito como por exemplo a compatibilidade com a API do NetBSD 9.0 e com melhorias do NetBSD-current, suporte tanto a Intel quanto AMD e já há um processo de upstream NVMM para o Qemu e quando estiver pronto, o backend do NVMM no Qemu deve funcionar bem no DragonflyBSD out of the box (e disponível do Dports).

O planejamento interno da Motriz Systems é de terminar o projeto até o dia 1° de Setembro de 2020 e todo o projeto será publicado nos seguintes links:

https://github.com/Moritz-Systems/DragonFlyBSD (como branch e pull requested para o próximo link)
https://github.com/DragonFlyBSD/DragonFlyBSD (os desenvolvedores do DragonFlyBSD irão testar os patches e integrar de acordo com as regras do code bounties).

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.

D-Bus será substituído no systemd

D-Bus é um sistema de comunicação de inter-processo (em inglês = inter-process communication ou IPC) que é utilizado como uma das dependências do systemd para ativação de serviços. Não somente pelo systemd, porém o D-Bus é utilizado por vários outros serviços como durante durante o processo de instalação gerando um número de identificação para a máquina através do D-Bus machine id. Máquinas virtuais também dependem o D-Bus machine id ainda mais em casos de geração de templates que podem precisar de um novo D-Bus machine ID para garantir que recursos do sistema do hypervisor sejam instruídos para o guest correto. O comando dbus-uuidgen --get é utilizado verificar o id das máquinas enquanto que o comando bus-uuidgen --ensure é utilizado para validação sendo o dbus-uuidgen --ensure=/etc/machine-id é utilizado para gerar novo id após remover o link simbólico /etc/machine-id tendo origem em /var/lib/dbus/machine-id (fica aí essa dica para a LPIC1).

Ferramentas do D-Bus

O Varlink também é um sistema de comunicação de inter-processo porém, sendo um protocolo que visa tornar os serviços acessíveis tanto para humanos quanto para máquinas do jeito mais fácil possível fazendo uso de arquivos de texto para descrever interface com todos os tipos de dados, metodo e etc.; não faz uso de números mágicos ou valores sem nomes, é fácil de debugar com qualquer ferramenta.

Screenshots - VARLINK

O desenvolvedor Benno Rice do projeto FreeBSD disse em sua palestra sobre o systemd:

"Eu não sou um grande fã do D-Bus, mas eu sou um grande fã de mensagens" ... "logs binários não é uma coisa ruim desde que você tem as ferramentas para separá-las, mas gosta de mensagens".

Mas o motivo que o Varlink está sendo adotado no systemd no lugar do D-Bus não está relacionado a coisas como logs serem ou não binários e sim por questões de limitações sendo uma delas só estar disponível após o processo de boot, demora na implementação de novos recursos, complexidade, o fato de utilizar somente serialização, não podendo ser utilizado em muitos serviços básicos, performance baixa dentre outros problemas. Todos os detalhes podem ser conferidos na apresentação do Lennart no FOSDEM deste ano:

Varlink: a protocol for IPC

Site oficial do Varlink

varlink · GitHub

Mais sobre o systemd pode ser conferido aqui no blog

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

Lançado DragonFlyBSD 6.4.0

No dia 30 de Dezembro foi lançada a série 6.4 que trás muitas novidades como novo suporte a hypervisor type-2 com NVMM, driver GPU da AMD, correções de segurança e novo recuso (experimental) no remote-mount de volumes do HAMMER2.

O Hammer2 ainda recebeu sete correções de bug e muitas limpezas de sintax além de mais alguns novos recursos como Report critical bulkfree transitions que não devem acontecer, Validação de número de inode on-media, Definição mais correta da flag read-only em montagem e falha ao montar se o volume root não for especificado. Houveram melhorias de desempenho, correções e novos recursos também no tmpfs, msdosfs e no ext2fs. O comando makefs agora possui suporte ao HAMMER2, alocação extra de inodes quando deixar espaço livre em imagens UFS e correção de calculo de tamanho de arquivos enquanto que o comando newfs_hammer2 - recebeu uma correção na opção "-V 1".

O kernel do DragonflyBSD recebeu 10 correções sendo algumas criticas permitindo até exploit local. Mas também recebeu novos recursos como mlockall()'s MCL_CURRENT que correspondem com às expectativas do tipo linux ; suporte a API gtaskqueue do FreeBSD entre outros recursos.

Na parte de redes houveram correções no ipfw, no pf, no IPV6 e no if_bridge. O utrwn agora possui suporte a if_bridge e o jail permite allow_raw_sockets. A parte gráfica também recebeu correções e melhorias no drm e no evdev.

Melhorias e correções no userspace como nos comandos date, lpr, last, /bin/sh, xargs (Sync com FreeBSD) e fetch; correções e melhorias em bibliotecas (o total de 17) e atualizações de comandos de terceiros como os comandos awk, less e file.

Todas as atualizações do DragonflyBSD série 6.4.0 podem ser conferidas clicando aqui.

Baixe o DragonflyBSD 6.4.0 clicando aqui.

Mais sobre o DragonflyBSD pode ser lido clicando aqui.

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

Lançado novo Minicurso de atributos no Linux

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

Star Lab anuncia suporte de segurança ao KVM

Hoje, dia 23 de Janeito de 2024 a Star Lab Corp® anunciou o lançamento do suporte da ferramenta de segurança Titanium para o KVM. Devido ao crescimento do emprego da virtualização em ambientes corporativos e de defesa (forças armadas) nos Estados Unidos, incluindo o crescimento da adoção do KVM no Red Hat Enterprise Linux, a Star Lab estendeu o emprego do Titanium para o ambiente de virtualização.

Titanium é considerada a tecnologia de proteção para Linux em ambientes de missão critica nas forças armadas como:

secure boot
data-at-rest protections
mandatory access controls (mac)
kernel hardening
E agora, segurança em ambientes de virtualização com KVM

O primeiro anuncio de suporte a KVM em Outubro de 2022, mas a Star Lab já vem trabalhando de 2020 para trazer soluções de segurança para ambiente virtualizado. Não há previsão para suporte em outros hypervisor como VMware mesmo que detenha uma grande fatia do mercado devido a sua facilidade de uso, seu modelo proprietário dificulta os esforços para alcançar grande efeito na tecnologia de proteção.

"... Mas o Titanium para KVM será a única solução que permite programas de defesa aproveitem os benefícios da virtualização enquanto também se tornam FMS-ready. Estamos confiantes de que os programas adotarão com entusiasmo a economia de custos e a redução de riscos que acompanham o Titanium for KVM."

Mais sobre Titanium for KVM e outras tecnologias de segurança da Star Lab security podem ser conferidas no seu site oficial.

Titanium for KVM — Star Lab Software

Star Lab Announces Capability to Secure KVM Hypervisors

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

Nova documentação do DragonFlyBSD

Estou um pouco atrasado com essa postagem que eu gostaria de já ter postado assim que fiquei sabendo, mas aqui estou eu (antes tarde do que nunca). Recentemente postei um artigo sobre o DragonflyBSD passar a receber suporte a Hypervisor do OpenBSD. Pouco depois disso fiquei sabendo de uma nova documentação que foi feita para o DragonflyBSD.

Um cara chamado Vincent DEFERT criou ebooks no formato EPUB para o DragonflyBSD (um handbook e um HowTo com misselanias). Os dois ebooks estão disponíveis em seu site oficial que podem ser baixados clicando aqui.

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.

CURSO DE SHELL SCRIPT DO MATEUS MÜLLER

Cursos na Udemy

Estrutura de sistema de arquivo parte I

Escrevi um artigo tratado de benchmark de filesystems. Por que então não tratarmos desta vez de como um sistema de arquivo é estruturado nos *nix?

Estrutura de sistema de arquivo parte I

Sistema de arquivo é o método de armazenar e organizar coleções arbitrária de dados em uma forma utilizável a humanos.
Quem acompanha o canal Toca do Tux já deve ter assistido o vídeo "Filesystems (vale a pena saber?)" onde narro um pouco sobre o assunto.:

Antes de dar inicio ao assunto quero fazer um esclarecimento. Vi certa vez um amigo compartilhar em uma rede social como o sistema de arquivo é estruturado e fez o seguinte comentário:

Se notarem, esse meu amigo fez até a observação corrigindo o que afirmam.

Essa informação não trata da estrutura do kernel. trata-se na verdade, de como os diretórios do sistema são estruturados dentro do sistema de arquivo.
Diretórios são em uma interface gráfica as pastas que visualizamos. O termo pasta foi adotado pela Apple para facilitar para os usuários (ficar algo, digamos, mais amigável).

As informações sobre para que serve cada diretório podem ser obtidas e lidas na documentação FHS. O FHS (Filesystem Hierarchy Standard) é a documentação que define e descreve a utilidade de cada diretório, quais diretórios são necessários, quais são opcionais e quais são sugeridos nos sistemas Unix (uma herança que os Unix tem em comum).
Um dos escritores responsáveis pelo FHS foi Rusty Russell (conhecido também por ser o desenvolvedor que originalmente escreveu o Ipchains e o Netfilter/Iptables, iniciou o trabalho de desenvolvimento do Hypervisor Lguest no kernel Linux e em 2009 integrou a equipe do Samba).

Rusty Russell na conferência Australiana linux em Janeiro de 2011

man iptables

Existe também o Linux Filesystem Hierarchy, que conheci quando a ultima versão do FHS era a 2.1. Hoje em dia FHS é mantido pela Linux Foundation na sua ultima versão, que é a 3.0, o nome de Rusty Russel permanece lá (ele merece os créditos por suas contribuições feitas). É uma documentação que vale a leitura.

Mais informações:

Lançado Unleashed 1.3

illumOS ganha um fork

Unleashed é um fork do sistema operacional illumOS (e sendo o illumOS um fork do Open Solaris e por sua vez, um derivado do Solaris). O meu primeiro vídeo no canal eu relatei um pouco sobre o Open Solaris já que havia ouvido pessoas dizendo que se tratava de uma distribuição Linux. Caso não saiba o que é um fork, eu tenho um artigo aqui no blog que pode conferir e entender melhor, basta clicar aqui ;)

Automaticamente o Unleashed herda as características do Open Solaris como o ZFS, o DTrace e o Crossbow e vários outros recursos que podem ser conferidos clicando aqui. Veja aqui meu antigo vídeo sobre o Open Solaris.

Existem vários em torno de oito distribuições derivadas do illumOS; cada um desses destinado a soluções diferentes como Workstation, servidores, storages e Hypervisor. A lista de distribuições derivadas do illumOS que podem ser conferidas clicando aqui ou visualizando a imagem abaixo.

Distribuições derivadas do illumOS

Esse fork surgiu pela comunidade acreditar que poderia fazer melhor do que os derivados do illumOS adotando uma postura diferente em relação à compatibilidade e redução de interações de códigos, buscando modernizar o sistema operacional através da remoção de código legado. Com isso, apesar de um descendente do Solaris, o Unleased torna-se binariamente incompatível com o Solaris por removerem um monte de partes (digamos) sujas.

A comunidade quer adotar um ambiente de compilação diferente já que do illumOS é antigo. Querem que o ./configure seja o suficiente para a maioria dos programas (sem ser necessário ficar especificando flags ou lincar bibliotecas adicionais).
sendo o

Curso Linux: Da migração a administração do sistema operacional

CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.

Essa é uma comunidades sendo totalmente Open Source (não pretendem ter binários proprietários e nem blobs no sistema operacional), com uma liderança limpa, um sistema operacional completo, com lançamentos periódicos (um a cada três meses com patches de segurança entre os lançamentos),

https://www.unleashed-os.org/

https://www.unleashed-os.org/why.html

http://lists.31bits.net/archives/devel/2019-April/000052.html

NÃO SE ESQUEÇA DE SE INSCREVER NOCURSO DE SHELL SCRIPT DO MATEUS MÜLLER
Cursos na Udemy

Páginas