Contexto

Estou executando um sistema Red Hat Enterprise Linux versão 8.5 em uma VM em um VMWare ESXI.

Eu precisava de mais espaço em um volume lógico preciso chamado lv_pmpnaquela VM:

$ lsblk
NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                            8:0    0   80G  0 disk
├─sda1                         8:1    0  600M  0 part /boot/efi
├─sda2                         8:2    0    1G  0 part /boot
└─sda3                         8:3    0 78,4G  0 part
  ├─VGslash-lv_root          253:0    0 19,5G  0 lvm  /
  ├─VGslash-lv_swap          253:1    0    4G  0 lvm  [SWAP]
  ├─VGslash-lv_usr           253:2    0    8G  0 lvm  /usr
  ├─VGslash-lv_srv           253:3    0    2G  0 lvm  /srv
  ├─VGslash-lv_home          253:4    0    2G  0 lvm  /home
  ├─VGslash-lv_opt           253:5    0    4G  0 lvm  /opt
  ├─VGslash-lv_tmp           253:6    0    4G  0 lvm  /tmp
  ├─VGslash-lv_var_log_audit 253:7    0  512M  0 lvm  /var/log/audit
  ├─VGslash-lv_var_log       253:8    0    1G  0 lvm  /var/log
  ├─VGslash-lv_vartmp        253:9    0 10,4G  0 lvm  /var/tmp
  ├─VGslash-lv_var           253:10   0    3G  0 lvm  /var
  └─VGslash-lv_pmp           253:11   0   20G  0 lvm  /pmp
sr0                           11:0    1 1024M  0 rom

Então redimensionei o disco da VM para 500G nas propriedades do VSphere que apareceram na sdaparte:

$ lsblk
NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                            8:0    0  500G  0 disk
├─sda1                         8:1    0  600M  0 part /boot/efi
├─sda2                         8:2    0    1G  0 part /boot
└─sda3                         8:3    0 78,4G  0 part
  ├─VGslash-lv_root          253:0    0 19,5G  0 lvm  /
  ├─VGslash-lv_swap          253:1    0    4G  0 lvm  [SWAP]
  ├─VGslash-lv_usr           253:2    0    8G  0 lvm  /usr
  ├─VGslash-lv_srv           253:3    0    2G  0 lvm  /srv
  ├─VGslash-lv_home          253:4    0    2G  0 lvm  /home
  ├─VGslash-lv_opt           253:5    0    4G  0 lvm  /opt
  ├─VGslash-lv_tmp           253:6    0    4G  0 lvm  /tmp
  ├─VGslash-lv_var_log_audit 253:7    0  512M  0 lvm  /var/log/audit
  ├─VGslash-lv_var_log       253:8    0    1G  0 lvm  /var/log
  ├─VGslash-lv_vartmp        253:9    0 10,4G  0 lvm  /var/tmp
  ├─VGslash-lv_var           253:10   0    3G  0 lvm  /var
  └─VGslash-lv_pmp           253:11   0   20G  0 lvm  /pmp
sr0                           11:0    1 1024M  0 rom

Em seguida, redimensionei o sda3volume físico para corresponder ao espaço em disco recém-adicionado com

$ resizepart /dev/sda 3 1000000000
$ pvresize /dev/sda3

$ lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                            8:0    0   500G  0 disk
├─sda1                         8:1    0   600M  0 part /boot/efi
├─sda2                         8:2    0     1G  0 part /boot
└─sda3                         8:3    0 476,9G  0 part
  ├─VGslash-lv_root          253:0    0  19,5G  0 lvm  /
  ├─VGslash-lv_swap          253:1    0     4G  0 lvm  [SWAP]
  ├─VGslash-lv_usr           253:2    0     8G  0 lvm  /usr
  ├─VGslash-lv_srv           253:3    0     2G  0 lvm  /srv
  ├─VGslash-lv_home          253:4    0     2G  0 lvm  /home
  ├─VGslash-lv_opt           253:5    0     4G  0 lvm  /opt
  ├─VGslash-lv_tmp           253:6    0     4G  0 lvm  /tmp
  ├─VGslash-lv_var_log_audit 253:7    0   512M  0 lvm  /var/log/audit
  ├─VGslash-lv_var_log       253:8    0     1G  0 lvm  /var/log
  ├─VGslash-lv_vartmp        253:9    0  10,4G  0 lvm  /var/tmp
  ├─VGslash-lv_var           253:10   0     3G  0 lvm  /var
  └─VGslash-lv_pmp           253:11   0    20G  0 lvm  /pmp
sr0                           11:0    1  1024M  0 rom

Aumentei o lv_pmptamanho do volume lógico:

$ lvextend /dev/mapper/VGslash-lv_pmp -l+100%FREE

E atualizou o sistema de arquivos para que ele detectasse o novo tamanho:

$ xfs_growfs /dev/mapper/VGslash-lv_pmp

Até agora tudo bem, obtive o tamanho que esperava no lv_pmpvolume lógico:

$ lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                            8:0    0   500G  0 disk
├─sda1                         8:1    0   600M  0 part /boot/efi
├─sda2                         8:2    0     1G  0 part /boot
└─sda3                         8:3    0 476,9G  0 part
  ├─VGslash-lv_root          253:0    0  19,5G  0 lvm  /
  ├─VGslash-lv_swap          253:1    0     4G  0 lvm  [SWAP]
  ├─VGslash-lv_usr           253:2    0     8G  0 lvm  /usr
  ├─VGslash-lv_srv           253:3    0     2G  0 lvm  /srv
  ├─VGslash-lv_home          253:4    0     2G  0 lvm  /home
  ├─VGslash-lv_opt           253:5    0     4G  0 lvm  /opt
  ├─VGslash-lv_tmp           253:6    0     4G  0 lvm  /tmp
  ├─VGslash-lv_var_log_audit 253:7    0   512M  0 lvm  /var/log/audit
  ├─VGslash-lv_var_log       253:8    0     1G  0 lvm  /var/log
  ├─VGslash-lv_vartmp        253:9    0  10,4G  0 lvm  /var/tmp
  ├─VGslash-lv_var           253:10   0     3G  0 lvm  /var
  └─VGslash-lv_pmp           253:11   0 418,4G  0 lvm  /pmp
sr0                           11:0    1  1024M  0 rom    

Problema

O problema surge assim que reinicio o sistema: ele parece perder as alterações de tamanho que fiz no sda3volume físico, o que consequentemente impede que o lv_pmpvolume lógico seja montado (pois ele assume que não há espaço suficiente no PV pai):

$ lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                            8:0    0   500G  0 disk
├─sda1                         8:1    0   600M  0 part /boot/efi
├─sda2                         8:2    0     1G  0 part /boot
└─sda3                         8:3    0  76,9G  0 part
  ├─VGslash-lv_root          253:0    0  19,5G  0 lvm  /
  ├─VGslash-lv_swap          253:1    0     4G  0 lvm  [SWAP]
  ├─VGslash-lv_usr           253:2    0     8G  0 lvm  /usr
  ├─VGslash-lv_srv           253:3    0     2G  0 lvm  /srv
  ├─VGslash-lv_home          253:4    0     2G  0 lvm  /home
  ├─VGslash-lv_opt           253:5    0     4G  0 lvm  /opt
  ├─VGslash-lv_tmp           253:6    0     4G  0 lvm  /tmp
  ├─VGslash-lv_var_log_audit 253:7    0   512M  0 lvm  /var/log/audit
  ├─VGslash-lv_var_log       253:8    0     1G  0 lvm  /var/log
  ├─VGslash-lv_vartmp        253:9    0  10,4G  0 lvm  /var/tmp
  └─VGslash-lv_var           253:10   0     3G  0 lvm  /var
sr0                           11:0    1  1024M  0 rom 

Solução alternativa

É possível colocá-lo de volta em forma executando os seguintes comandos manualmente após a reinicialização:

### Re-apply physical volume changes
$ resizepart /dev/sda 3 1000000000
$ pvresize /dev/sda3
### Re-scan logical volumes
$ vgscan --mknodes -v
$ vgchange -a y

Pergunta

Por que isso está acontecendo? E o que posso fazer para evitar isso?

Não sei se isso está relacionado ao próprio sistema operacional, ao ambiente da VM ou a algum outro fator que não controlo. Qualquer conselho a esse respeito também ajudaria.

A solução alternativa acima não é realmente satisfatória, mesmo que eu pudesse colocá-la em um script na inicialização, ter que executar essa ação a cada inicialização não parece certo: não faz sentido para mim que uma alteração no tamanho do volume não persista após uma reinicialização.

Quero fazer uma pequena vmware vm linux rodando um único microserviço. VM e serviço requerem algumas opções como endereço IP, certificado TLS com chave, arquivo de configuração.

Existe alguma maneira padrão de passar esses parâmetros do hipervisor para a VM?

Tenho a ideia de fazer um segundo hdd minúsculo para a vm para armazenar alguns arquivos de configuração. Talvez haja outra maneira de passar opções personalizadas para o sistema operacional da vm como o Docker faz?

Ok, pessoal, antes de mais nada, peço desculpas por fazer uma pergunta que provavelmente é estúpida e com uma resposta simples, mas NÃO consigo descobrir isso.

Cerca de um ano atrás, assumi uma nova posição em uma empresa com uma pequena presença de datacenter. O material DC equivale a um conjunto de discos e um chassi Cisco UCS 5108 AC2 com 6 blades B200 M4. Executamos VMWare nesta configuração, ESXi 5.5. Sim, é muito antigo; estou migrando para AWS, então, por favor, não faça sombra :-)

De qualquer forma, eu gerencio o VMWare do vCenter rodando em uma caixa Windows rodando 2012 R2 Standard. E meu problema é este: eu não sei onde diabos está essa caixa Windows.

• Não há VMs do Windows no vCenter.
• Não há VMs em execução "diretamente no Cisco UCS".
• Não há outros recursos de computação em nossos racks (por exemplo, nenhuma pequena caixa de pizza 1U circulando por aí)

Não estou no DC, mas pedi aos caras do controle remoto que tirassem fotos dos nossos dois racks e todo o equipamento está presente e contabilizado na minha planilha de inventário.

FWIW o endereço IP da caixa do Windows é um IP privado em nosso intervalo. E quando eu faço RDP na caixa e executo o Gerenciador de Dispositivos, vejo que o modelo e a série da CPU correspondem às CPUs em todas as lâminas. Então isso me diz que a caixa do Windows de fato roda em algum lugar no UCS. Mas como eu disse, não consigo encontrá-lo nem no vCenter nem no software gerenciador do UCS.

Existe alguma estação de gerenciamento misteriosa ou função de supervisão do UCS que eu não conheça?

Estou construindo um cluster vSAN que consiste em 2 racks, cada um com 3 nós (este será eventualmente um cluster estendido). Cada rack está em sub-redes diferentes, conforme listado abaixo:

Rack 1:

• Gerenciamento: 10.73.8.0/25 (Gateway: 10.73.8.126)
• vMotion: 10.73.10.0/25 (Gateway: 10.73.10.126)
• vSAN: 10.73.11.0/25 (Gateway: 10.73.10.126)

Rack 2:

• Gestão: 10.73.8.128/25 (Gateway: 10.73.8.254)
• vMotion: 10.73.10.128/25 (Gateway: 10.73.10.254)
• vSAN: 10.73.11.128/25 (Gateway: 10.73.10.254)

Eu construí o cluster com todos os nós no Rack 1. Sem problemas. Tudo funciona e tenho algumas VMs de teste em execução. Quando tento adicionar nós do Rack 2 ao mesmo cluster, recebo um erro "partição de cluster vSAN". Aqui está o que eu verifiquei/testei:

1. Tenho conectividade completa de ponta a ponta entre TODOS os nós (o vmkping entre nós em ambos os racks funciona em todas as sub-redes com mensagens de tamanho MTU sem fragmentação)
2. A lista de agentes unicast em todos os nós mostra corretamente todos os outros nós com os UUIDs, endereços IP e impressões digitais de certificado corretos.
3. Eu tentei várias permutações de sair/entrar no cluster com os nós particionados.

Todo o meu google-fu indicou que meu problema deveria ser um dos acima, mas não parece ser o caso. Até adicionei rotas estáticas para as redes vSAN, embora eu tenha substituído os gateways padrão definidos nas vmks do vSAN. Sem dados.

Eu sei que isso é estranho, mas se alguém puder me indicar outras causas para esse erro, ficaria muito grato.

Estou construindo um cluster de 6 nós espalhados por 2 racks (isso eventualmente será configurado como um cluster estendido com uma testemunha separada). Tudo é ESXi 8.0U1. Cada rack está em uma sub-rede L3 diferente. Configurei o rack 1 e configurei um cluster vSAN com 3 nós nesse cluster, implantei algumas VMs de teste e tudo está funcionando bem. Quando comecei a adicionar nós do rack 2, acabei com os três problemas a seguir:

• Partição de cluster SAN
• vMotion: verificação de conectividade básica (unicast)
• vMotion: verificação de MTU

Estou estacionando o erro de partição de cluster do vSAN por enquanto, pois o do vMotion deve ser facilmente solucionável. Se eu usar SSH para os nós no Rack 1, posso executar vmk em todas as interfaces do vMotion (usando -S vMotion) no Rack 1, mas não consigo executar ping na interface do vMotion dos nós no Rack 2. Ele falha com o erro:

sendto() falhou (a rede está inacessível)

Confirmei que o gateway padrão está configurado para a interface vMotion e está correto. Além disso, se eu adicionar um novo adaptador VMK a cada nó em ambos os racks usando o mesmo grupo de portas distribuídas do vMotion com IPs na mesma sub-rede e configurado com o mesmo gateway (mas usando a pilha de IP padrão!), posso executar ping entre nós em ambos prateleiras.

Parece que há algum problema com a lógica de roteamento da interface do vMotion, mas além da configuração do gateway padrão, não tenho certeza do que mais há para configurar aqui.

Estou me concentrando neste erro do vMotion, pois estou me perguntando se é o mesmo problema raiz da partição vSAN.

Alguém pode me indicar alguma direção de depuração?

Para maior clareza:

Rack 1:

• Sub-rede de gerenciamento: 10.73.8.0/25 (GW: 10.73.8.126)
• Sub-rede vMotion: 10.73.10.0/25 (GW: 10.73.10.126)
• Sub-rede vSAN: 10.73.11.0/25 (GW: 10.73.11.126)

Rack 2:

• Sub-rede de gerenciamento: 10.73.8.128/25 (GW: 10.73.8.254)
• Sub-rede vMotion: 10.73.10.128/25 (GW: 10.73.10.254)
• Sub-rede vSAN: 10.73.11.128/25 (GW: 10.73.11.254)

Answer: Finalmente descobri para quem se depara com isso. O gateway teve que ser configurado na pilha TCP/IP do vMotion, além de ser configurado no próprio adaptador VMK...

Alocamos 0,2 + 10,98 T, mas o uso de armazenamento mostra que ele usa 14T por quê？

2 discos são ambos “Thin provisioned”

Em um ambiente de laboratório, removi o único uplink do vSwitch (queria adicionar a nic a outro vSwitch - mas perdi a conectividade). Agora não consigo me conectar ao ESXi. Eu não tenho vCenter.

Existe uma maneira de adicionar a interface de rede de volta ao vSwitch e restaurar a conectividade? Também não consigo SSH para ESXI. A reinstalação é a única maneira?

O servidor de um cliente que estou administrando executa a versão mais recente do VMware ESXi - 8.0U2 Enterprise Plus, mas acredito que isso tem acontecido desde que comecei a usar o ESXi, muitas versões atrás.

Sempre que você faz login no Web client do vSphere e clica em VMs, a lista é exibida em ordem aleatória (possivelmente na ordem em que foram adicionadas). Você deve se lembrar de classificá-los de AZ. Às vezes, se você não prestar atenção, VMs com nomes semelhantes podem aparecer no local onde você normalmente esperaria ver outra (quando classificada como AZ).

Como podemos manter a lista de VMs classificada em ordem alfabética, permanentemente?

Falando sobre ESXi/vSphere em cada servidor individual, não no vCenter.

Procurei on-line e a resposta não parece ser facilmente aparente.

Aqui está um exemplo de captura de tela de outro usuário:

Minha pergunta básica é: é possível usar o vCenter para aplicar uma atualização de componente ao host, visto que eu precisaria desligar as VMs para fazer isso, e crucialmente 1 delas é uma VM roteadora e outra é vCenter em si?

Acabei de fazer uma instalação limpa do ISO mais recente do ESXi, 8.0 U2. Instalei um roteador VM + implantei a versão mais recente do vCenter Server Appliance. Será meu único servidor por enquanto - não posso usar outro servidor para migrar essas VMs.

Vejo no vCenter 8 que eles querem que você use imagens do Lifecycle Manager, pois removerão Lifecycle Baselines/VUM na próxima versão do vCenter 9. Não usei nenhum deles antes.

Meu servidor está atualizado com a imagem mais recente, de acordo com a aba Atualizações no vCenter; no entanto, ele contém uma versão mais antiga do smartpqidriver (version 4495) e eu gostaria de instalar a versão mais recente deste driver de componente ( smartpqiversion 4600) que ainda não está disponível no ESXi ISO mais recente.

Fui ao Lifecycle Manager e fiz uma atualização de importação com o pacote offline fornecido pela VMware para o driver - que é a versão 4600comparada com a versão mais recente disponível na imagem que é 4495.

Em seguida, editei a imagem anexada ao host para adicionar o componente adicional e executei uma pré-verificação:

Vejo que preciso desligar minhas VMs para executar a atualização.

Se eu fizer isso, precisarei desligar o pfSense (roteador VM) + vCenter.

Como o vCenter aplicará a atualização se a VM estiver desligada e não tiver roteamento?

A atualização começará a ser aplicada assim que eu desligar todas as VMs?

Será necessária alguma interação do usuário durante o processo de atualização? (O servidor é remoto para mim, eu poderia solicitar uma sessão KVM, mas não é gratuita)

Este é o método correto para aplicar a atualização do componente?

Este é apenas o driver da peça de hardware. Porém, tenho mais algumas vibrações para instalar para outras coisas relacionadas, e a documentação do fabricante do hardware sugere o uso esxcli software vib installpara fazer isso. Usar esse método para instalar o driver seria uma ideia melhor do que imagens do Lifecycle Manager? Isso é o que também é sugerido na documentação do fabricante do driver, usando o próprio .vibarquivo fornecido.

Estou preocupado que os .vibarquivos extras que o fabricante do hardware deseja que eu instale após este driver possam esperar a 4600versão do componente principal do driver.

À parte: percebo na captura de tela que diz que o Quick Boot não é compatível com este host, mas quando clico em Remediar ele está habilitado nas opções - devo desabilitar isso?

Precisamos diminuir o tamanho de um disco VM, temos 2 discos no Hardware Virtual dessa máquina virtual, um deles tem 8 TB mas no final são usados ​​​​apenas 600 GB.

Configuração atual:

Se tentarmos colocar um tamanho de disco menor, nas configurações da VM, obtemos um erro e não alteramos.

Configuração desejada:

Eu sei que apenas 600 GB são usados ​​​​de verdade e não 8 TB, mas precisamos ter certeza de que o tamanho do disco nunca atingirá mais de 1 TB, por exemplo.

Não sei se podemos cancelar o registro da VM, criar uma nova e adicionar os discos existentes com novos tamanhos de disco para resolver isso ou o que podemos fazer.

Cumprimentos,

Tentamos usar o Thin Provision, mas ainda não nos permite diminuir o tamanho do disco.

O sistema operacional convidado é o Windows Server 2019