Mostrar mensagens com a etiqueta Virtualização. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Virtualização. Mostrar todas as mensagens

quinta-feira, 5 de outubro de 2023

VirtualBox - Linux Guest Aditions

 Testado com host VirtualBox 7.0 e guest Lubuntu 20.04 LTS.

 

Para utilizar o Guest Aditions é necessário instalar kernel modules (cf. https://www.virtualbox.org/manual/ch02.html#externalkernelmodules), no caso do Lubuntu já tem os headers instalados foi apenas necessário instalar GCC e make:

sudo apt install gcc make

De seguida é necessário ir a Devices e Insert Guest Aditions CD... De onde será necessário executar com sudo o instalador para linux:

sudo ./VBoxLinuxAdditions.run

Para aceder a pastas partilhadas do host no guest é necessário adicionar o grupo vboxsf ao utilizador no guest (cf. https://dev.to/rahedmir/virtualbox-cannot-access-shared-folder-items-permission-denied-fixed-59mi):

sudo usermod -a -G vboxsf utilizador

Depois de reiniciar é possível aceder a pastas partilhadas do host.

terça-feira, 7 de março de 2017

Proxmox VE 4 | upgrade a partir de 3.x

Ao instalar o Promox VE 4 utilizei ZFS RAID1 (com dois discos de 2TB).

Após a instalação do Proxmox VE são apresentados dois armazenamentos:
- local
- local-zfs

Copiar dados e informação

Devem criar-se dumps dos contentores no servidor antigo (Proxmox 3.x) e anotar todas as informações de rede de cada um deles.
Após a criação dos dumps dos contentores, é necessário copiá-los para o novo servidor para se terminar depois o processo de migração [0].
- Montar disco com os dumps dos containers OpenVZ (feitos no Promox VE 3.x)
- Mover para /var/lib/vz/dump

O disco com a informação antiga estava com software RAID1. Assim, para aceder ao disco antigo (mdadm com RAID1) para copiar a informação para o novo host foi necessário [1]:
mount /dev/sdc2 /mnt/old_hdd
mount: unknown filesystem type 'linux_raid_member'

Para verificar o estado do RAID na partição
mdadm --examine /dev/sdd4

Para criar o dispositivo md
mdadm -A -R /dev/md1 /dev/sdc2

Para montar é necessário utilizar o mapper LVM para montar o volume com o nome pve-data:
mount /dev/mapper/pve-data /media/BACKUP

É possível agora copiar toda a informação para o novo host.

Migração de OpenVZ para LXC

Uma vez copiados os dumps, é necessário aceder ao armazenamento e escolher cada um dos dumps e restaurá-lo (Restore).
É necessário definir toda a configuração de rede de cada contentor antes de o arrancar.

Partilha de informação por bind mount

A partilha de informação via bind mount (montar uma pasta do host num ou vários contentores) continua a ser possível mas faz-se de forma diferente [2].
Adicionar no ficheiro conf do LXC em questão /etc/pve/lxc/100.conf (para o contentor 100):
mp0: /srv/DATA/media,mp=/srv/media

Onde mp0 é o primeiro ponto de montagem do contentor, /srv/DATA/media é a pasta no host a montar no cliente em /srv/media.
No total é possível especificar para cada contentor 10 pontos de montagem desta forma (mp0, mp1, mp2, etc).

Após a definição de todos os bind mount points de cada contentor é possível arrancar o contentor e confirmar se a informação está correta.



terça-feira, 27 de outubro de 2015

Proxmox/OpenVZ contentor sem permissões de escrita em /dev/null

Algumas VPS OpenVZ ao reiniciarem ficavam com permissões erradas (rw- --- ---, ou seja, 600) em alguns devices:
/dev/null
/dev/full
/dev/zero
/dev/random
/dev/urandom

A partir daqui [1] foi possível obter uma regra para o udev aplicar sobre estes devices e permitir que a cada arranque as permissões sejam as corretas.

Como neste caso o ficheiro não existe é necessário criá-lo e adicionar o conteúdo abaixo.
# nano /etc/udev/rules.d/50-fix-permission.rules
SUBSYSTEM=="mem", KERNEL=="null|zero|full|random|urandom", MODE="0666"

Guardar com CTRL + X e Y

[1] - https://bbs.archlinux.org/viewtopic.php?pid=1123209#p1123209

quinta-feira, 27 de novembro de 2014

rsyslogd em openVZ utiliza 100% de CPU

Num contentor openVZ do ubuntu 14.04 o processo do rsyslogd pode ocupar 100% de CPU.

A solução passa por aceder ao container que contém o processo problemático:
vzctl enter 101

Parar o serviço:
service rsyslog stop

Alterar a configuração do rsyslog:
sed -i -e 's/^\$ModLoad imklog/#\$ModLoad imklog/g' /etc/rsyslog.conf

Arrancar o serviço novamente:
service rsyslog start

Após este procedimento o processo já comporta normalmente.

[1] - Ron Fish @ Turnkey Linux forums - rsyslog spinning CPU on openvz
http://www.turnkeylinux.org/forum/support/20131211/rsyslog-spinning-cpu-openvz

sábado, 2 de março de 2013

Proxmox - Aumentar disco de VM

Para aumentar o espaço do disco de uma máquina virtual (VM) com Windows 2003 Server é necessário fazer algumas considerações:

  • É necessário desligar a VM
  • Aumentar o disco de boot (C:) não é suportado pelo Windows 2003 Server
  • Convém efetuar backup dos dados contidos no disco a dimensionar

1. Redimensionar o disco no Proxmox

Depois de desligar a máquina convém efetuar um backup da mesma, que é uma operação algo demorada, acedendo à aba Backup e criando um novo backup.

Resta depois aceder por SSH ao servidor e efetuar o redimensionamento do disco (ficheiro) associado à VM, da qual é necessário saber o identificador, neste caso aparecerá XXX, e o nome do ficheiro, neste caso diskimage.zzz.

cd /var/lib/vz/images/XXX

Depois, utilizando o comando qemu-img é possível redimensionar o ficheiro do disco, neste caso, acrescentando 100 gigabytes ao seu tamanho atual.

qemu-img resize diskimage.zzz +100G

2. Aumentar a partição para o tamanho do disco

Após o seu redimensionamento, o disco é visto no Proxmox como tendo o novo tamanho, contudo a partição de sistema (C:) continua com o mesmo tamanho e é necessário aumentá-la.

O grande problema é que o Windows 2003 Server apenas permite efetuar o redimensionamento de partições básicas (sem ser a de sistema). Assim, será necessário utilizar um software que proceda a este redimensionamento.

Nota: No caso do Windows 7, Vista ou 2008 Server, o próprio sistema permite, no serviço de gestão de discos, efetuar o redimensionamento da partição de sistema (C:).

Assim, a forma mais simples é executar um LiveCD que possua o Gparted (por exemplo, Parted Magic ou o Grml). Neste caso, foi possível efetuar o arranque por PXE (para saber mais sobre isto veja aqui) e carregar o Grml.

Após o arranque em modo gráfico é possível aceder ao Gnome Partition Editor, onde facilmente se consegue redimensionar a partição de sistema, gravar as alterações e reiniciar a VM.

3. Arrancar o Windows 2003 Server

Ao arrancar a VM após o redimensionamento da partição, será feito um CHKDSK à partição, que permitirá assim corrigir qualquer erro que possa ter havido no processo de redimensionamento.

Após a conclusão deste processo a VM estará a funcionar como antes, apenas possuindo mais espaço em disco.

sábado, 7 de julho de 2012

Proxmox VE v.2 - Software RAID

Instalação do servidor de virtualização Proxmox Virtual Environment versão 2 utilizando software RAID (não suportado nativamente).

Tutorial: petercarrero.com

0. Pré-requisitos:

  1. Instalar software necessário
  2. Preparar os discos para RAID
  3. Colocar /boot em /dev/md0
  4. Mover o PVE LVM para /dev/md1

1. Instalar software necessário

All you really need here is the mdadm package. I also install vim because I like it better than plain vi. On Proxmox VE 1.0 you also needed the initramfs-tools, but this is already installed on VE 2.0. So, to get your system ready, type the following on the command line of your Proxmox setup:
apt-get update; apt-get install mdadm vim

The mdadm package will prompt you for information and all you need to do on that screen is press the ENTER key.

2. Prepare raid devices

Now that you have the right software setup, let's get your raid devices ready. We will copy the partition information from /dev/sda into /dev/sdb, convert the partitions on sdb to raid members, initialize the raid devices and then save the raid configuration on /etc/mdadm/mdadm.conf so it persists after reboot. All that is done with the following 6 lines:
sfdisk -d /dev/sda | sfdisk -f /dev/sdb
sfdisk -c /dev/sdb 1 fd
sfdisk -c /dev/sdb 2 fd
mdadm --create -l 1 -n 2 /dev/md0 missing /dev/sdb1
mdadm --create -l 1 -n 2 /dev/md1 missing /dev/sdb2
mdadm --detail --scan >> /etc/mdadm/mdadm.conf

3. Get /boot ready on /dev/md0

This is by far the step with the most number of commands, but we got quite a bit to do here… It may be possible to shorten some of these steps, but I wasn't successful on my attempts to simplify this and the instructions below worked pretty well for me. Anyway, let's begin by formatting and populating /dev/md0 with the contents of /boot.
mkfs.ext3 /dev/md0
mkdir /mnt/md0
mount /dev/md0 /mnt/md0
cp -ax /boot/* /mnt/md0


Now let's tell our system to use /dev/md0 after the Linux bootstrap (i.e.: grub2 will still use sda1 to boot for now).
vim /etc/fstab

Replace the line that has UUID=<your UUID here> /boot ext3 defaults 0 1 with /dev/md0 /boot ext3 defaults 0 1. If you are unfamiliar with vim, use the arrow keys to navigate to the line above, hit yypi# to make a copy of the old line and then turn the copy into a comment, use the up-arrow to go to the uncommented line, delete all the UUID=bla text and add /dev/md0. After that is done, hit the ESC key, which will take you out of insert mode, then :wq followed by the ENTER key. That will save and quit the file for you. We are now done with vim! Once you are on the command line again, reboot with the following command:
reboot


After the system reboots, let's verify that it is using the md0 device as your /boot mount point by typing the following:
mount|grep boot

You should get something like this:
/dev/md0 on /boot type ext3 (rw)

Now we go on to tell grub to use that device during boot as well on the next 10 commands:
echo '# customizations' >> /etc/default/grub
echo 'GRUB_DISABLE_LINUX_UUID=true' >> /etc/default/grub
echo 'GRUB_PRELOAD_MODULES="raid dmraid"' >> /etc/default/grub
echo raid1 >> /etc/modules
echo raid1 >> /etc/initramfs-tools/modules
grub-install /dev/sda
grub-install /dev/sdb
grub-install /dev/md0
update-grub
update-initramfs -u

Maybe you don't need all 3 grub-install commands, but for me, not having the last one there didn't work and when reverting the process during one of my tests, I ended-up having to reissue the command grub-install /dev/sda.


We are almost done with this step! All that remains to do is make /dev/sda1 part of /dev/md0 and reboot using this config to make sure all is working at it should. We get that done with the following 2 commands:
sfdisk -c /dev/sda 1 fd
mdadm --add /dev/md0 /dev/sda1

This will get /dev/md0 rebuilding, and it shouldn't take long. You can verify the progress of the process with the following command:
watch -n 5 cat /proc/mdstat

Once that is completed, reboot and we are done with this step!
reboot

4. Move the PVE LVM to /dev/md1

Now the process is pretty much similar to the old one. This step is simple, but it is the one that could take the longest time to complete, depending on how big your data partition is and how fast is your system. What we need to do is vacate /dev/sda2 so we can join it to /dev/md1, and we do this with the following commands: (warning: the pvmove command can take a long time to complete, so use it on a tty or inside a screen session)
pvcreate /dev/md1
vgextend pve /dev/md1
pvmove /dev/sda2 /dev/md1
vgreduce pve /dev/sda2
pvremove /dev/sda2
sfdisk --change-id /dev/sda 2 fd
mdadm --add /dev/md1 /dev/sda2

You will get your second raid rebuilding after the last mdadm command. This will take longer than the 1st one and you can check its progress the same way as before, with:
watch -n 5 cat /proc/mdstat

However, this time it may be good to boost the limits with which the RAID subsystem can read and write to its devices. You do that with the following commands:
echo 800000 > /proc/sys/dev/raid/speed_limit_min
echo 1600000 > /proc/sys/dev/raid/speed_limit_max


Hopefully this guide will save you some time and quite possibly a lot of head-ache and frustration! If you like it or if you have a suggestion to improve on it in any way, please leave me a comment below.