Le redimensionnement du disque en ligne est-il possible avec KVM?

15

Nous évaluons KVM pour la virtualisation Linux sur quelques projets. Jusqu'ici tout va bien. Mais l'une de nos exigences est la possibilité d'ajouter de l'espace disque à un invité en cours d'exécution sans redémarrer ni le mettre hors ligne. Est-ce possible avec KVM?

La seule chose que j'ai trouvée jusqu'à présent (mais que je n'ai pas encore testée) est la possibilité de connecter à chaud des disques à la machine. Si je choisis cette route, je pourrais toujours ajouter le nouveau disque à un groupe de volumes LVM sur l'invité, puis étendre le volume logique choisi. Le plus gros inconvénient de cette approche est qu'au fil du temps, nous pourrions nous retrouver avec des invités disposant d'un nombre variable de disques virtuels. L'espace disque "réel" serait fourni à l'hôte via un SAN, nous pouvons donc toujours ajouter plus d'espace à l'hôte à chaque fois.

Eil
la source
(Et "Oui", c'est possible.)
poige

Réponses:

4

Je pense que vous êtes coincé à faire ce que vous avez mentionné si vous voulez le faire sans démonter la machine.

Pourquoi ne pas simplement donner les LUN des machines virtuelles directement sur le SAN et gérer l'espace là-bas? Cela fonctionne mieux si vous souhaitez utiliser des fonctionnalités telles que la migration en direct de toute façon.

KVM est basé sur QEMU donc tout son support de format d'image provient de ce projet. Voici une bonne façon de redimensionner les différents formats pris en charge par Qemu / KVM. Mais le forum Qemu serait un bon endroit pour poser cette question si vous n'obtenez pas de réponses solides ici.

Une autre option qui peut ne pas être idéale consiste à utiliser un qcow2 vraiment grand ou un autre format d'image clairsemé pour les lecteurs. Vous pouvez donc donner à chaque machine un petit lecteur pour le système d'exploitation et une grande image clairsemée pour les données sous LVM. Cela conserverait au moins le nombre de lecteurs / images virtuels que vous devez gérer. Mais ce provisionnement fin pourrait être un problème si vous le faites pour 1000 machines et que tout le monde vous occupe sur l'espace libre qu'il voit.

Je pense que XEN a les mêmes limites actuellement.

3dinfluence
la source
Après un examen plus approfondi, le montage du stockage SAN à partir de l'invité lui-même, comme vous le mentionnez, est probablement la voie à suivre. Et merci également pour les informations supplémentaires.
Eil
le provisionnement fin peut également être coûteux en raison de la fragmentation.
wazoox
15

Je sais que c'est une vieille question, mais je l'ai trouvée en cherchant la solution sur Google et j'espère que cela peut aider quelqu'un d'autre.

Aujourd'hui, il est possible de redimensionner le disque dur de la machine. J'ai trouvé un moyen de travailler ici:

https://bugzilla.redhat.com/show_bug.cgi?id=648594

Les étapes suivantes doivent être effectuées:

  1. Trouvez un nom de fichier et un nom de périphérique KVM du disque dur que vous souhaitez redimensionner:

    root@vhstage02:/data# virsh dumpxml test | xpath -e /domain/devices/disk
    Found 2 nodes in stdin:
    -- NODE --
    <disk type="file" device="disk">
      <driver name="qemu" type="qcow2" />
      <source file="/data/test.img" />
      <backingStore />
      <target dev="vda" bus="virtio" />
      <alias name="virtio-disk0" />
      <address type="pci" domain="0x0000" bus="0x00" slot="0x04" function="0x0" />
    </disk>
    -- NODE --
    <disk type="file" device="cdrom">
      <driver name="qemu" type="raw" />
      <source file="/data/images/debian-8.2.0-amd64-netinst.iso" />
      <backingStore />
      <target dev="hda" bus="ide" />
      <readonly />
      <alias name="ide0-1-1" />
      <address type="drive" controller="0" bus="1" target="0" unit="1" />
    </disk>
    

Le disque qui nous intéresse est le disque. Vous devez rechercher sourceet aliasbloquer. Pour moi, le nom de fichier est test.imget le nom d'alias est virtio-disk0. À ce nom, vous devez ajouter le préfixe drive-pour obtenir le nom du lecteur qemu.

  1. Maintenant, nous redimensionnons réellement le lecteur à l'aide du moniteur qemu:

    virsh qemu-monitor-command test block_resize  drive-virtio-disk0  100G --hmp
    

Notez que le nom de fichier a été utilisé sans l'extension .img et que le lecteur a été ajouté à l'alias de disque. Le 100G est la taille résultante du disque que nous voulons avoir

  1. Connectez-vous à la machine et vérifiez que la taille réelle a été modifiée:

    root@test:~# fdisk -l
    
    Disk /dev/vda: 100 GiB, 107374182400 bytes, 209715200 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0x7e6e7f71
    
    Device     Boot  Start       End   Sectors  Size Id Type
    /dev/vda1  *      2048    499711    497664  243M 83 Linux
    /dev/vda2       501758 167770111 167268354 79.8G  5 Extended
    /dev/vda5       501760 167770111 167268352 79.8G 8e Linux LVM
    

C'est ça! Vous pouvez maintenant créer de nouvelles partitions ou redimensionner des partitions existantes.

alexK
la source
1
Merci d'être revenu et d'avoir ajouté cette réponse! Rend les choses beaucoup plus simples que l'ancienne façon de procéder.
Dave Sherohman
4

AFAIK, ce n'est pas possible - vous pouvez ajouter de nouvelles images de disque, et comme vous le faites remarquer, vous pouvez également ajouter de nouvelles images à un volume LVM, mais pour redimensionner une image de disque amorçable active, vous devez pouvoir la fermer et éditez les partitions.

Voici une bonne explication pour agrandir une image. Bien qu'il nécessite un arrêt, vous pourriez probablement vous en sortir avec seulement quelques minutes de temps d'arrêt, surtout si vous évitez l'option --nonsparse image et dd le disque gparted dans un fichier iso et montez à l'avance dans votre invité KVM. J'espère que cela t'aides.

nedm
la source
2
Le problème n'est pas réellement lié à KVM; sous Linux, vous ne pouvez tout simplement pas redimensionner le disque à partir duquel vous avez démarré. Cela s'applique également aux matrices RAID physiques.
wazoox
3

Il est possible de déplacer un système Linux entre des disques pendant son fonctionnement. La limitation est que vous ne pouvez pas modifier les partitions sur un disque qui a des partitions utilisées.

Pour ce faire, votre système de fichiers racine doit être sur un LVM, cela signifie souvent que vous devez avoir un système de fichiers de démarrage séparé (ce n'est cependant pas essentiel, cela rend les choses plus faciles)

Après avoir branché le nouveau disque, vous l'ajoutez au LVM avec vgextend, utilisez pvmove pour déplacer les rootfs vers le nouveau disque, utilisez respectivement lvextend et resize2fs pour développer le volume logique et le système de fichiers, puis utilisez vgreduce pour supprimer l'ancien disque du volume groupe. Une fois retiré, l'ancien volume peut être débranché.

Pour le cas simple, vous avez un petit disque pour le système de fichiers de démarrage que vous n'avez jamais à toucher. Mais si c'est tout seul c'est facile de le démonter, de le débrancher, d'en brancher un nouveau et de reconstruire le disque de démarrage sans arrêter le système. (ne vous plantez pas pendant que vous le faites)

Remarque: resize2fs peut également réduire les systèmes de fichiers.

Robert
la source
0

Pas possible atm, mais afaik c'est une fonctionnalité en cours de développement. Ce que vous pouvez faire à la place est de vous connecter à une cible iSCSI à partir de la machine virtuelle et de gérer l'espace sur cette cible du côté SAN.

Dyasny
la source
Vous n'avez pas répondu à la question avec une réponse qu'il peut utiliser.
Mei
@David: et qu'est-ce qui vous fait penser cela et même dévaloriser ma réponse? Comment ma réponse ne fournit-elle pas une solution de contournement au problème en question?
dyasny
Vous avez dit "Pas possible atm ..." puis lui avez parlé d'une fonctionnalité qui n'est pas possible pour le moment. (Maintenant, presque deux ans plus tard, cela pourrait être différent - mais cette réponse ne dit pas cela.)
Mei
1
Il y a donc deux ans, j'aurais dû lui dire "ce sera possible dans deux ans"? Ai-je l'air d'un prophète pour toi? À l'époque, le branchement à chaud était en cours de développement, et c'est exactement ce que j'ai dit. Ensuite, j'ai proposé une approche différente pour attacher le stockage à la machine virtuelle, qui serait indépendante de l'ensemble des fonctionnalités de qemu. Je n'ai jamais dit que c'était la seule approche, mais c'est un moyen.
dyasny
Je comprends maintenant ... J'ai modifié votre réponse pour mieux montrer votre intention.
Mei