Solution 1 :
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 pourra aider quelqu'un d'autre.
Quant à aujourd'hui, c'est c'est possible de redimensionner le disque dur sur la machine. J'ai trouvé une méthode de travail ici :
https://bugzilla.redhat.com/show_bug.cgi?id=648594
Les étapes suivantes doivent être effectuées :
-
Trouvez un nom de fichier et un nom de périphérique KVM pour le disque dur que vous souhaitez redimensionner :
[email protected]:/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>
Celui qui nous intéresse est le disque. Vous devriez rechercher source et alias blocs. Pour moi, le nom du fichier est test.img et le nom d'alias est virtio-disk0 . À ce nom, vous devez ajouter drive- pour obtenir le nom du lecteur qemu.
-
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
-
Connectez-vous à la machine et vérifiez que la taille réelle a été modifiée :
[email protected]:~# 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 désormais soit créer de nouvelles partitions, soit redimensionner celles qui existent déjà.
Solution 2 :
AFAIK, ce n'est pas possible - vous pouvez ajouter de nouvelles images de disque, et comme vous le soulignez, 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. vers le bas et modifiez les partitions.
Voici une bonne explication pour agrandir une image. Bien qu'il nécessite un arrêt, vous pourriez probablement vous en tirer avec seulement quelques minutes de temps d'arrêt, surtout si vous évitez l'option d'image --nonsparse et ajoutez le disque gparted à un fichier iso et montez à l'avance dans votre invité KVM. J'espère que cela vous aidera.
Solution 3 :
Je pense que vous êtes obligé de faire ce que vous avez mentionné si vous voulez le faire sans démonter la machine.
Pourquoi ne pas simplement donner des LUN aux 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 un bon guide pour 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 n'est peut-être pas idéale consiste à utiliser un très grand format qcow2 ou un autre format d'image clairsemée pour les lecteurs. Vous pouvez donc donner à chaque machine un petit lecteur pour le système d'exploitation et une grande image fragmentée pour les données sous LVM. Cela permettrait au moins de conserver le nombre de lecteurs/images virtuels que vous devez gérer. Mais ce provisionnement léger pourrait être un problème si vous le faites sur 1000 machines et que tout le monde vous prend sur l'espace libre qu'ils voient.
Je crois que XEN a les mêmes limitations actuellement.
Solution 4 :
Il est possible de déplacer un système Linux d'un disque à l'autre pendant son exécution. La limitation est que vous ne pouvez pas modifier les partitions sur un disque qui a des partitions en cours d'utilisation.
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 facilite simplement les choses)
Après avoir branché le nouveau disque, vous l'ajoutez au LVM avec vgextend, utilisez pvmove pour déplacer le rootfs vers le nouveau disque, utilisez lvextend et resize2fs pour développer respectivement 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 disposez d'un petit disque pour le système de fichiers de démarrage auquel vous n'avez jamais à toucher. Mais si c'est tout seul, c'est facile pour le démonter, débranchez-le, branchez-en un nouveau et reconstruisez 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.