[Liste-clx] LVM et Xen sont sur un disque dur......

[VANHULLEBUS Yvan]

[.....]
> > Avec la solution décrite, l'host peut allouer plus de disque aux
> > guest, et les guests gèrent eux même leurs partoches. Oui ça fait 2
> > resize2fs mais si c'est que ça...
> 
> Ca fait au pire 2 resize, mais si par exemple je veux juste répartir
> autrement à l'interieur d'un Dom0, le LVM du Dom0 n'est même pas
> impacté....
> 
> Si je fais un resize au niveau du Dom0 (dans le bon sens), le LVM du
> guest détecte l'augmentation/la diminution de taille du device
> automatiquement au démarrage suivant, ou la manip est quand même plus
> compliquée dans ce cas ?
> 
> Pour reprendre mon exemple, si je fais un:
> xl shutdown VM1
> lvextend -L+5G /dev/vg0/VM1_disk
> xl create <...>/VM1.xl
> 
> il se passe quoi au niveau de ma VM ?
> un 'vgdisplay vg_vm1' m'indiquera automatiquement la nouvelle taille ?
> (je me doute que je devrai faire aussi un "lvextend
> ... /dev/vg_vm1/xxx" à un moment).

J'ai creusé un peu sur ce point, et il semblerait que la réponse soit
"c'est sale"......

Genre le pv du guest ne bouge pas, faut aller créer une nouvelle
partition sur l'espace disque qui est apparu, la rajouter en tant que
pv sur le vg, puis faire un lvextend....
Du coup, je n'ose même pas imaginer une réduction !


Donc j'ai cherché une autre solution...... j'en suis revenu à l'idée
de faire des partitions LVM au niveau de l'hyperviseur et de les
passer en direct en tant que partitions au guest.
Ca pose quelques petits tracas vu que le guest n'a pas de MBR ou
équivalent, mais rien de vraiment très problématique pour pygrub.


Pour résoudre le problème d'une liste de lv longue comme mon bras et
de la conf xen qui va avec (ca se gère, surtout que je ne fais pas de
nouvelles VMs tous les jours, c'est surtout que ca compliquerait pas
mal le fait de faire des snaps plus tard), j'ai réfléchi un peu à
l'usage que j'ai des répertoires sur ces VMs, de ce que je veux
segmenter, etc....

La conclusion, c'est que j'ai en gros 3 zones:

- /var, /home (quand ce n'est pas le /home nfs, y'a pratiquement rien
  dedans) et /tmp (que je peux éventuellement mettre en tmpfs, selon
  la RAM que j'aurai au total), qui contiennent les données standard
  mobiles.

- /srv qui contient les données "pour faire le job" du serveur (une
  base de données ici, une racine web par là, une base LDAP ailleurs,
  etc.....)

- le reste, qui est en gros le système, qui ne doit pas bouger sauf
  quand j'installe un nouveau service ou que je fais une mise à
  jour..... donc que j'aimerais bien avoir d'un bloc (au sens lv), et
  idéalement en lecture seule la plupart du temps.....

Ah, et un swap, mais ca ne compte qu'à moitié :)

Du coup, je vais tenter de faire un guest comme ca, avec un lv_root
qui serait monté en read-only la plupart du temps (ce qui a l'air un
peu technique mais tout à fait faisable), un lv_var qui stocke
également le mini-home et tmp, et un lv_srv qui contient les données
du serveur, pour pouvoir faire un snap des données à part.
(et un lv_swap, donc).

Si je veux faire un snap, ca me fait au max 3 lv concernées, ce qui
est encore assez rapide à faire (et facilement scriptable si je nomme
mes lvs de façon pas trop débile).


L'étape ultime de ca, ca serait d'avoir un lv_root qui serait lui même
un snap d'un autre lv, que je mettrais à jour en dehors de la VM, mais
ca pose des complications supplémentaires, entre autres lors de mise à
jour de packages qui vont aller faire des opérations de maintenance
sur les données.....