Amigos, após futricar um pouco, consegui descobrir o mecanismo para fazer upgrade da versão 5.1 para versão 5.2 do proxmox.
Não é apenas "apt update && apt dis-upgrade" na CLI como diz em vários lugares, mesmo na documentação oficial.
Para poder fazer o upgrade, alterei o arquivo /etc/apt/sources.d/pve-enterprise.list:
#deb https://enterprise.proxmox.com/debian/pve stretch pve-enterprise
deb http://download.proxmox.com/debian stretch pve-no-subscription
Por fim, aí sim, "apt update && apt dis-upgrade".
CUIDADO: Este repositório não deve ser usado para servidores em produção.
Envoy yourself!
PS: Achei informações na documentação oficial (https://pve.proxmox.com/wiki/Package_Repositories)
sexta-feira, 3 de agosto de 2018
terça-feira, 18 de outubro de 2016
OMSA: Firmware/Driver Information for Controller PERC 6/i Integrated
Minimum Required Driver Version2.24.00.32
Windows 2008 x86
http://www.dell.com/support/home/br/pt/brbsdt1/Drivers/DriversDetails?driverId=CW1N9
http://downloads.dell.com/FOLDER00353674M/1/SAS-RAID_Driver_CW1N9_WN32_2.24.0.32_A03.EXE
Windows 2008 x86
http://www.dell.com/support/home/br/pt/brbsdt1/Drivers/DriversDetails?driverId=CW1N9
http://downloads.dell.com/FOLDER00353674M/1/SAS-RAID_Driver_CW1N9_WN32_2.24.0.32_A03.EXE
segunda-feira, 4 de maio de 2015
ZFS sobre volume iscsi (initiator com open-iscsi). ZVOL entregue sob iscsi (target com iscsitarget). Isto no novíssimo Debian Jessie.
Temos um storage que pensei em dar uma incrementada e prover uma solução de backup e preservação de dados utilizando ZFS. A ideia foi "por que não criar um pool ZFS em um volume do storage e entregar um ZVOL através de iscsi para uso, seja pelo servidor de arquivos ou XenServer?"
Como não posso atualizar o sistema operacional do storage, para isto precisaria de um host intermediário com duas interfaces de rede, uma ligada ao storage, outra para o initiator.
Neste host intermediário instalei o novíssimo Debian Jessie (https://www.debian.org/CD/http-ftp/#stable) e ZoL (http://zfsonlinux.org/debian.html).
Instalei os pacotes open-iscsi e iscsitarget. Depois disto foi só alterar alguns arquivos de configuração.
Logo depois de instalado o open-iscsi e antes dos comandos iscsiadm para descoberta de luns, alterei o arquivo /etc/iscsi/iscsid.conf, substituindo a linha "node.startup = manual" por "node.startup = automatic".
Com o advento do systemd, tive que fazer muita experimentação até conseguir fazer com que a ordem de execução dos daemons open-iscsi, zfs e iscsitarget ocorressem exatamente nesta ordem:
1º open-iscsi para conexão à lun do storage;
2º zfs para importação do pool criado e descrito em /etc/zfs/zpool.cache;
3º iscsitarget para disponibilizar volumes iscsi para outros initiators a partir de dispositivos ZFS, os ZVOLs.
Eis as alterações necessárias nos daemons para que se cumpra esta ordem:
1º open-scsi:
não exige alteração alguma;
2º zfs:
alteração do arquivo /lib/systemd/system/zfs-mount.service:
adicionar comentário na linha "#Before=local-fs.target";
adicionar a linha "After=open-iscsi.service"
3º iscsitarget:
adicionar "zfs-mount nas linhas
# Required-Start: $remote_fs $syslog $network $time procps zfs-mount
# Required-Stop: $remote_fs $syslog $network $time procps zfs-mount
Finalizando, já havia tido alguma experiência com falta de memória para o sistema operacional, devido ao cache do ZFS (provavelmente), que consegui contornar com a seguinte linha em /etc/sysctl.conf:
"vm.min_free_kbytes=1048576 "
Pronto! Reiniciando e tudo estando disponível automaticamente logo após o boot, basta fazer uso da lun pelos initiators. Depois basta criar snapshots e exportá-los, para preservação de dados e criação de backups.
Como não posso atualizar o sistema operacional do storage, para isto precisaria de um host intermediário com duas interfaces de rede, uma ligada ao storage, outra para o initiator.
Neste host intermediário instalei o novíssimo Debian Jessie (https://www.debian.org/CD/http-ftp/#stable) e ZoL (http://zfsonlinux.org/debian.html).
Instalei os pacotes open-iscsi e iscsitarget. Depois disto foi só alterar alguns arquivos de configuração.
Logo depois de instalado o open-iscsi e antes dos comandos iscsiadm para descoberta de luns, alterei o arquivo /etc/iscsi/iscsid.conf, substituindo a linha "node.startup = manual" por "node.startup = automatic".
Com o advento do systemd, tive que fazer muita experimentação até conseguir fazer com que a ordem de execução dos daemons open-iscsi, zfs e iscsitarget ocorressem exatamente nesta ordem:
1º open-iscsi para conexão à lun do storage;
2º zfs para importação do pool criado e descrito em /etc/zfs/zpool.cache;
3º iscsitarget para disponibilizar volumes iscsi para outros initiators a partir de dispositivos ZFS, os ZVOLs.
Eis as alterações necessárias nos daemons para que se cumpra esta ordem:
1º open-scsi:
não exige alteração alguma;
2º zfs:
alteração do arquivo /lib/systemd/system/zfs-mount.service:
adicionar comentário na linha "#Before=local-fs.target";
adicionar a linha "After=open-iscsi.service"
3º iscsitarget:
adicionar "zfs-mount nas linhas
# Required-Start: $remote_fs $syslog $network $time procps zfs-mount
# Required-Stop: $remote_fs $syslog $network $time procps zfs-mount
Finalizando, já havia tido alguma experiência com falta de memória para o sistema operacional, devido ao cache do ZFS (provavelmente), que consegui contornar com a seguinte linha em /etc/sysctl.conf:
"vm.min_free_kbytes=1048576 "
Pronto! Reiniciando e tudo estando disponível automaticamente logo após o boot, basta fazer uso da lun pelos initiators. Depois basta criar snapshots e exportá-los, para preservação de dados e criação de backups.
terça-feira, 30 de dezembro de 2014
Debian: xHCI xhci_drop_endpoint called with disabled ep
Passei a utilizar um computador Positivo com usb3.0 que estava me deixando maluco com as mensagem "xHCI xhci_drop_endpoint called with disabled ep" no log... muitas mensagens. Acredito até que eu estava tendo lentidão no acesso a dispositivos usb devido a isto.
Como atualmente não utilizo nenhum dispositivo usb3.0 acabei por tentar desabilitar o uso do módulo xhci com os seguintes arquivos em /etc/modprobe.d
Arquivo xhci com o conteúdo:
options xhci enable=0
e o arquivo xhci_hcd com o conteúdo:
options xhci_hcd enable=0
Provavelmente funcione com somente o segundo arquivo, mas como testei assim e já funcionou, fica a dica.
Como atualmente não utilizo nenhum dispositivo usb3.0 acabei por tentar desabilitar o uso do módulo xhci com os seguintes arquivos em /etc/modprobe.d
Arquivo xhci com o conteúdo:
options xhci enable=0
e o arquivo xhci_hcd com o conteúdo:
options xhci_hcd enable=0
Provavelmente funcione com somente o segundo arquivo, mas como testei assim e já funcionou, fica a dica.
quinta-feira, 23 de outubro de 2014
rsync "cannot delete non-empty directory"
Se a execução do rsync está lhe causando arrepios com a mensagem "cannot delete non-empty directory" quando se está utilizando --delete para que o que é excluído na origem seja refletido no destino, pode ser que esteja acontecendo o mesmo que mim.
Inicialmente meu rsync era assim:
rsync -avh --delete
E então alterei para isto:
rsync -avh --exclude=Thumbs.db --delete
Acabou acontecendo de muitos arquivos Thumbs.db continuarem no destino e o --delete não observa que eles foram excluídos na origem, porque eles continuam lá. Então o que temos a fazer é --delete-excluded, para que estes arquivos que estão na origem, mas foram filtrados, e não queremos que eles continuem no destino, porque ficaram lá por uma alteração de política de rsync:
rsync -avh --delete-excluded --exclude=Thumbs.db --delete
Inicialmente meu rsync era assim:
rsync -avh --delete
E então alterei para isto:
rsync -avh --exclude=Thumbs.db --delete
Acabou acontecendo de muitos arquivos Thumbs.db continuarem no destino e o --delete não observa que eles foram excluídos na origem, porque eles continuam lá. Então o que temos a fazer é --delete-excluded, para que estes arquivos que estão na origem, mas foram filtrados, e não queremos que eles continuem no destino, porque ficaram lá por uma alteração de política de rsync:
rsync -avh --delete-excluded --exclude=Thumbs.db --delete
segunda-feira, 30 de junho de 2014
ZFS no Debian Jessie (testing) - parte 3
Tenho armazenado, no meu sistema de arquivos zfs, algumas imagens .vdi de máquinas virtuais do VirtualBox na tentativa de ter um acesso a disco um pouco mais acelerado devido à raidz implantada.
Quem tiver curiosidade sobre o processo de implementação do pool zfs pode verificar em:
Infelizmente notei que após carregar as máquinas virtuais em ficava com a memória praticamente lotada e mesmo depois de desligar as máquinas virtuais a memória continuava lotada sendo que nada era cache. E quando digo lotado é basicamente 6GB de meus 8GB de RAM.
Por acaso resolvi encerrar todos os processos e dar um "modprobe -r zfs". Após isto é que tive meus GBs de memória de volta.
Como não fazia a mínima ideia de como contornar esta situação, após alguma pesquisa cheguei neste post: Excessive memory use with ZFS [SOLVED sort of].
Ainda estou avaliando a solução, mas prontamente já tive uma melhora no cenário, sendo que não cheguei a ficar com mais de 4GB comprometidos. Isto com o meu sistema desktop carregado, com o Iceweasel aberto e muitas abas.
Basicamente a solução consistem em criar o arquivo /etc/modprobe.d/zfs.conf com o conteúdo:
options zfs zfs_arc_max=2147483648
Pelo que entendi este valor seria em bytes e serve como a quantidade máxima de memória utilizada pelo sistema de cache do ZFS o ARC.
Mais informações sobre o tunning do ARC em http://docs.oracle.com/cd/E26502_01/html/E29022/chapterzfs-3.html.
Quem tiver curiosidade sobre o processo de implementação do pool zfs pode verificar em:
Infelizmente notei que após carregar as máquinas virtuais em ficava com a memória praticamente lotada e mesmo depois de desligar as máquinas virtuais a memória continuava lotada sendo que nada era cache. E quando digo lotado é basicamente 6GB de meus 8GB de RAM.
Por acaso resolvi encerrar todos os processos e dar um "modprobe -r zfs". Após isto é que tive meus GBs de memória de volta.
Como não fazia a mínima ideia de como contornar esta situação, após alguma pesquisa cheguei neste post: Excessive memory use with ZFS [SOLVED sort of].
Ainda estou avaliando a solução, mas prontamente já tive uma melhora no cenário, sendo que não cheguei a ficar com mais de 4GB comprometidos. Isto com o meu sistema desktop carregado, com o Iceweasel aberto e muitas abas.
Basicamente a solução consistem em criar o arquivo /etc/modprobe.d/zfs.conf com o conteúdo:
options zfs zfs_arc_max=2147483648
Pelo que entendi este valor seria em bytes e serve como a quantidade máxima de memória utilizada pelo sistema de cache do ZFS o ARC.
Mais informações sobre o tunning do ARC em http://docs.oracle.com/cd/E26502_01/html/E29022/chapterzfs-3.html.
quinta-feira, 12 de junho de 2014
ZFS no Debian Jessie (testing) - parte 2
Continuando o exposto na primeira parte deste tutorial (bom, vou chamá-lo assim agora) em http://meumaravilhosomundolivre.blogspot.com.br/2014/06/zfs-no-debian-jessie-testing.html, partimos para a resolução de alguns inconvenientes encontrados ao compilar e instalar o ZFS a partir do repositório git.
Notei que, depois de criado um sistema de arquivos de tamanho fixo, o dispositivo de bloco correspondente não era criado.
ls -al /dev/zvol/mypool01/data
ls: não é possível acessar /dev/zvol/mypool01/data: Arquivo ou diretório não encontrado
O problema é que nem mesmo /dev/zvol existia, então eis os passos para contornar isto.
cp /usr/lib/udev/rules.d/69-vdev.rules /etc/udev/rules.d
ZFS_UNMOUNT=yes
ZFS_SHARE=no
Foi importante que o script zfs-mount rodasse na inicialização para que não fosse necessário rodar um simples "zpool status" para que o dispositivo de bloco correspondentes ao sistema de arquivos mypool01/data aparecesse logo após o sistema carregado.
Notei que, depois de criado um sistema de arquivos de tamanho fixo, o dispositivo de bloco correspondente não era criado.
- Criar o sistema de arquivos com tamanho fixo e verificar a existência do dispositivo de bloco correspondente:
ls -al /dev/zvol/mypool01/data
ls: não é possível acessar /dev/zvol/mypool01/data: Arquivo ou diretório não encontrado
O problema é que nem mesmo /dev/zvol existia, então eis os passos para contornar isto.
- Copiar os arquivos udev para o local correto:
cp /usr/lib/udev/rules.d/69-vdev.rules /etc/udev/rules.d
- Criar o arquivo /etc/default/zfs com o conteúdo:
ZFS_UNMOUNT=yes
ZFS_SHARE=no
- Confirmar a execução do script /etc/init.d/zfs-mount na inicialização padrão:
Foi importante que o script zfs-mount rodasse na inicialização para que não fosse necessário rodar um simples "zpool status" para que o dispositivo de bloco correspondentes ao sistema de arquivos mypool01/data aparecesse logo após o sistema carregado.
Assinar:
Postagens (Atom)