Jean Baptiste FAVRE a écrit :- Découper le disque en "blocs" de 10Go
- Créer un VG par machine Xen. Au départ, ce VG ne comprend qu'un PV
(bloc) de 10Go, libre à moi d'en ajouter par la suite avec vgextend. A
priori, on ne peut pas partage un PV entre plusieurs VG.
- Dans le VG, créer autant de LV que la mahcine Xen en a besoin. Ce
seront les partition de la machine XEN. Je pourrai les
agrandir/rétrécir avec lvextend
Salut,
Ca ne répond pas à ta question, mais j'aimerai connaitre la finalité.
Si c'est la sécurité, tu peux recompiler Xen avec le mecanisme de
politique de sécurité qui te verrouillera les ressources et les domaines
pouvant tourner ensemble sur un même hyperviseur et quel domaine peut
accéder à quelle ressource.
Si c'est la souplesse, tu devrais plutot envisager un systeme de fichier
LVM LV qui te serve de modele et tu crées des snapshots en R/W pour
chaque domaine, auquel cas, tu dois les avoir sur le meme VG...
Je ne vois donc pas quelle raison peut te pousser à choisir une telle
architecture. Pourrais tu nous expliquer ?
Fanfan
Jean Baptiste FAVRE a écrit :
- Découper le disque en "blocs" de 10Go
- Créer un VG par machine Xen. Au départ, ce VG ne comprend qu'un PV
(bloc) de 10Go, libre à moi d'en ajouter par la suite avec vgextend. A
priori, on ne peut pas partage un PV entre plusieurs VG.
- Dans le VG, créer autant de LV que la mahcine Xen en a besoin. Ce
seront les partition de la machine XEN. Je pourrai les
agrandir/rétrécir avec lvextend
Salut,
Ca ne répond pas à ta question, mais j'aimerai connaitre la finalité.
Si c'est la sécurité, tu peux recompiler Xen avec le mecanisme de
politique de sécurité qui te verrouillera les ressources et les domaines
pouvant tourner ensemble sur un même hyperviseur et quel domaine peut
accéder à quelle ressource.
Si c'est la souplesse, tu devrais plutot envisager un systeme de fichier
LVM LV qui te serve de modele et tu crées des snapshots en R/W pour
chaque domaine, auquel cas, tu dois les avoir sur le meme VG...
Je ne vois donc pas quelle raison peut te pousser à choisir une telle
architecture. Pourrais tu nous expliquer ?
Fanfan
Jean Baptiste FAVRE a écrit :- Découper le disque en "blocs" de 10Go
- Créer un VG par machine Xen. Au départ, ce VG ne comprend qu'un PV
(bloc) de 10Go, libre à moi d'en ajouter par la suite avec vgextend. A
priori, on ne peut pas partage un PV entre plusieurs VG.
- Dans le VG, créer autant de LV que la mahcine Xen en a besoin. Ce
seront les partition de la machine XEN. Je pourrai les
agrandir/rétrécir avec lvextend
Salut,
Ca ne répond pas à ta question, mais j'aimerai connaitre la finalité.
Si c'est la sécurité, tu peux recompiler Xen avec le mecanisme de
politique de sécurité qui te verrouillera les ressources et les domaines
pouvant tourner ensemble sur un même hyperviseur et quel domaine peut
accéder à quelle ressource.
Si c'est la souplesse, tu devrais plutot envisager un systeme de fichier
LVM LV qui te serve de modele et tu crées des snapshots en R/W pour
chaque domaine, auquel cas, tu dois les avoir sur le meme VG...
Je ne vois donc pas quelle raison peut te pousser à choisir une telle
architecture. Pourrais tu nous expliquer ?
Fanfan
Mais, en faisant quelques essais pour étayer mes dires, je m'aperçois
que les LV sont tout aussi adaptés. Mouarf...
Du coup, je ne comprends plus bien l'utilité des VG. M'enfin, je vais me
replonger dans les tutos LVM pour piger. J'ai dû raté un truc, c'est
clair :-(
Mais, en faisant quelques essais pour étayer mes dires, je m'aperçois
que les LV sont tout aussi adaptés. Mouarf...
Du coup, je ne comprends plus bien l'utilité des VG. M'enfin, je vais me
replonger dans les tutos LVM pour piger. J'ai dû raté un truc, c'est
clair :-(
Mais, en faisant quelques essais pour étayer mes dires, je m'aperçois
que les LV sont tout aussi adaptés. Mouarf...
Du coup, je ne comprends plus bien l'utilité des VG. M'enfin, je vais me
replonger dans les tutos LVM pour piger. J'ai dû raté un truc, c'est
clair :-(
En ayant un VG par machine XEN, je comptais simplifier leur
création/suppression.
Pour la création:
vgcreate VGxxx /dev/sdb1 par exemple. Le groupe de la machine Xen est créé.
Ensuite, lvcreate -n LVroot_xxx VGxxx et lvcreate -n LVswap_xxx VGxxx me
permettent de créer une partition "root" et une "swap" qui seront
utilisées dans la mahcine XEN.
Pour la suppression, un simple vgremove VGxxx suffit.
Du coup, je ne comprends plus bien l'utilité des VG.
En ayant un VG par machine XEN, je comptais simplifier leur
création/suppression.
Pour la création:
vgcreate VGxxx /dev/sdb1 par exemple. Le groupe de la machine Xen est créé.
Ensuite, lvcreate -n LVroot_xxx VGxxx et lvcreate -n LVswap_xxx VGxxx me
permettent de créer une partition "root" et une "swap" qui seront
utilisées dans la mahcine XEN.
Pour la suppression, un simple vgremove VGxxx suffit.
Du coup, je ne comprends plus bien l'utilité des VG.
En ayant un VG par machine XEN, je comptais simplifier leur
création/suppression.
Pour la création:
vgcreate VGxxx /dev/sdb1 par exemple. Le groupe de la machine Xen est créé.
Ensuite, lvcreate -n LVroot_xxx VGxxx et lvcreate -n LVswap_xxx VGxxx me
permettent de créer une partition "root" et une "swap" qui seront
utilisées dans la mahcine XEN.
Pour la suppression, un simple vgremove VGxxx suffit.
Du coup, je ne comprends plus bien l'utilité des VG.
Bonsoir,
La finalité est effectivement la souplesse, ou plus exactement
l'indépendance des XEN entre elles d'un point de vue système de fichi er.
L'aspect sécurité est également important mais viendra dans un seco nd
temps, dès que j'aurai réglé ce souci ;-)
Du coup, je ne comprends plus bien l'utilité des VG. M'enfin, je vais m e
replonger dans les tutos LVM pour piger. J'ai dû raté un truc, c'est
clair :-(
Bonsoir,
La finalité est effectivement la souplesse, ou plus exactement
l'indépendance des XEN entre elles d'un point de vue système de fichi er.
L'aspect sécurité est également important mais viendra dans un seco nd
temps, dès que j'aurai réglé ce souci ;-)
Du coup, je ne comprends plus bien l'utilité des VG. M'enfin, je vais m e
replonger dans les tutos LVM pour piger. J'ai dû raté un truc, c'est
clair :-(
Bonsoir,
La finalité est effectivement la souplesse, ou plus exactement
l'indépendance des XEN entre elles d'un point de vue système de fichi er.
L'aspect sécurité est également important mais viendra dans un seco nd
temps, dès que j'aurai réglé ce souci ;-)
Du coup, je ne comprends plus bien l'utilité des VG. M'enfin, je vais m e
replonger dans les tutos LVM pour piger. J'ai dû raté un truc, c'est
clair :-(
On Sat, Nov 08, 2008 at 10:31:02PM +0100, Jean Baptiste FAVRE wrote:Bonsoir,
La finalité est effectivement la souplesse, ou plus exactement
l'indépendance des XEN entre elles d'un point de vue système de fichier.
L'aspect sécurité est également important mais viendra dans un second
temps, dès que j'aurai réglé ce souci ;-)
[...]Du coup, je ne comprends plus bien l'utilité des VG. M'enfin, je vais me
replonger dans les tutos LVM pour piger. J'ai dû raté un truc, c'est
clair :-(
Le fait d'avoir un VG par machine virtuelle peut-être très utile dans un cluster.
Ce que je fais au boulot :
Chaque VM est stockée dans :
- un filesystem hébergé sur
- un LV, dans
- un VG, sur
- un PV qui correspond à
- une LUN de notre SAN (vu comme un disque)
Avec un système de cluster Heartbeat ou RedHatCluster Suite, on peut activer/désactiver un VG sur un serveur ou l'autre.
Si on veut pouvoir bouger une VM d'un serveur à un autre, soit on travaille directement au niveau disque (LUN),
soit au niveau VG.
Avec des machines suur LV, on ne pourrait pas les dissocier.
On Sat, Nov 08, 2008 at 10:31:02PM +0100, Jean Baptiste FAVRE wrote:
Bonsoir,
La finalité est effectivement la souplesse, ou plus exactement
l'indépendance des XEN entre elles d'un point de vue système de fichier.
L'aspect sécurité est également important mais viendra dans un second
temps, dès que j'aurai réglé ce souci ;-)
[...]
Du coup, je ne comprends plus bien l'utilité des VG. M'enfin, je vais me
replonger dans les tutos LVM pour piger. J'ai dû raté un truc, c'est
clair :-(
Le fait d'avoir un VG par machine virtuelle peut-être très utile dans un cluster.
Ce que je fais au boulot :
Chaque VM est stockée dans :
- un filesystem hébergé sur
- un LV, dans
- un VG, sur
- un PV qui correspond à
- une LUN de notre SAN (vu comme un disque)
Avec un système de cluster Heartbeat ou RedHatCluster Suite, on peut activer/désactiver un VG sur un serveur ou l'autre.
Si on veut pouvoir bouger une VM d'un serveur à un autre, soit on travaille directement au niveau disque (LUN),
soit au niveau VG.
Avec des machines suur LV, on ne pourrait pas les dissocier.
On Sat, Nov 08, 2008 at 10:31:02PM +0100, Jean Baptiste FAVRE wrote:Bonsoir,
La finalité est effectivement la souplesse, ou plus exactement
l'indépendance des XEN entre elles d'un point de vue système de fichier.
L'aspect sécurité est également important mais viendra dans un second
temps, dès que j'aurai réglé ce souci ;-)
[...]Du coup, je ne comprends plus bien l'utilité des VG. M'enfin, je vais me
replonger dans les tutos LVM pour piger. J'ai dû raté un truc, c'est
clair :-(
Le fait d'avoir un VG par machine virtuelle peut-être très utile dans un cluster.
Ce que je fais au boulot :
Chaque VM est stockée dans :
- un filesystem hébergé sur
- un LV, dans
- un VG, sur
- un PV qui correspond à
- une LUN de notre SAN (vu comme un disque)
Avec un système de cluster Heartbeat ou RedHatCluster Suite, on peut activer/désactiver un VG sur un serveur ou l'autre.
Si on veut pouvoir bouger une VM d'un serveur à un autre, soit on travaille directement au niveau disque (LUN),
soit au niveau VG.
Avec des machines suur LV, on ne pourrait pas les dissocier.
Du coup, je me suis orienté vers un PV sur mon disque, un VG
correspondant et un LV par machine virtuelle. Ce LV est vu comme un
disque par le DomU.
Sauf que du coup, je n'ai plus accès aux partitions DomU depuis le Dom0
pour, par exemple, monter le filesystem en cas de crash du DomU.
Je n'ai accès qu'au "disque" (le LV), mais ne vois pas les partitions
que le DomU y a créé.
Accessoirement, je suis aussi confronté à un problème pour
redimensionner une partition du DomU malgré un lvextend. Même à
l'intérieur du DomU, ça ne marche pas bien qu'il voie l'espace libre.
Mais c'est sans doute un peu HS ici.
Du coup, je me suis orienté vers un PV sur mon disque, un VG
correspondant et un LV par machine virtuelle. Ce LV est vu comme un
disque par le DomU.
Sauf que du coup, je n'ai plus accès aux partitions DomU depuis le Dom0
pour, par exemple, monter le filesystem en cas de crash du DomU.
Je n'ai accès qu'au "disque" (le LV), mais ne vois pas les partitions
que le DomU y a créé.
Accessoirement, je suis aussi confronté à un problème pour
redimensionner une partition du DomU malgré un lvextend. Même à
l'intérieur du DomU, ça ne marche pas bien qu'il voie l'espace libre.
Mais c'est sans doute un peu HS ici.
Du coup, je me suis orienté vers un PV sur mon disque, un VG
correspondant et un LV par machine virtuelle. Ce LV est vu comme un
disque par le DomU.
Sauf que du coup, je n'ai plus accès aux partitions DomU depuis le Dom0
pour, par exemple, monter le filesystem en cas de crash du DomU.
Je n'ai accès qu'au "disque" (le LV), mais ne vois pas les partitions
que le DomU y a créé.
Accessoirement, je suis aussi confronté à un problème pour
redimensionner une partition du DomU malgré un lvextend. Même à
l'intérieur du DomU, ça ne marche pas bien qu'il voie l'espace libre.
Mais c'est sans doute un peu HS ici.
Jean Baptiste FAVRE a écrit :
Du coup, je me suis orienté vers un PV sur mon disque, un VG
correspondant et un LV par machine virtuelle. Ce LV est vu comme un
disque par le DomU.
Sauf que du coup, je n'ai plus accès aux partitions DomU depuis le
Dom0 pour, par exemple, monter le filesystem en cas de crash du DomU.
Je n'ai accès qu'au "disque" (le LV), mais ne vois pas les partitions
que le DomU y a créé.
En effet le noyau ne s'attend pas à trouver des partitions sur un LV,
mais à ma connaissance seulement sur un disque "physique" (où du moins
vu comme tel : hdX, sdX) ou un volume RAID partitionnable. Mais de toute
façon tu aurais aussi rencontré le même problème avec un VG par domU, non ?
Il n'y aurait pas moyen d'accéder aux partitions du LV depuis un autre
domU ?
Accessoirement, je suis aussi confronté à un problème pour
redimensionner une partition du DomU malgré un lvextend. Même à
l'intérieur du DomU, ça ne marche pas bien qu'il voie l'espace libre.
Comment ça ?
Mais c'est sans doute un peu HS ici.
Bah, pourquoi ?
Jean Baptiste FAVRE a écrit :
Du coup, je me suis orienté vers un PV sur mon disque, un VG
correspondant et un LV par machine virtuelle. Ce LV est vu comme un
disque par le DomU.
Sauf que du coup, je n'ai plus accès aux partitions DomU depuis le
Dom0 pour, par exemple, monter le filesystem en cas de crash du DomU.
Je n'ai accès qu'au "disque" (le LV), mais ne vois pas les partitions
que le DomU y a créé.
En effet le noyau ne s'attend pas à trouver des partitions sur un LV,
mais à ma connaissance seulement sur un disque "physique" (où du moins
vu comme tel : hdX, sdX) ou un volume RAID partitionnable. Mais de toute
façon tu aurais aussi rencontré le même problème avec un VG par domU, non ?
Il n'y aurait pas moyen d'accéder aux partitions du LV depuis un autre
domU ?
Accessoirement, je suis aussi confronté à un problème pour
redimensionner une partition du DomU malgré un lvextend. Même à
l'intérieur du DomU, ça ne marche pas bien qu'il voie l'espace libre.
Comment ça ?
Mais c'est sans doute un peu HS ici.
Bah, pourquoi ?
Jean Baptiste FAVRE a écrit :
Du coup, je me suis orienté vers un PV sur mon disque, un VG
correspondant et un LV par machine virtuelle. Ce LV est vu comme un
disque par le DomU.
Sauf que du coup, je n'ai plus accès aux partitions DomU depuis le
Dom0 pour, par exemple, monter le filesystem en cas de crash du DomU.
Je n'ai accès qu'au "disque" (le LV), mais ne vois pas les partitions
que le DomU y a créé.
En effet le noyau ne s'attend pas à trouver des partitions sur un LV,
mais à ma connaissance seulement sur un disque "physique" (où du moins
vu comme tel : hdX, sdX) ou un volume RAID partitionnable. Mais de toute
façon tu aurais aussi rencontré le même problème avec un VG par domU, non ?
Il n'y aurait pas moyen d'accéder aux partitions du LV depuis un autre
domU ?
Accessoirement, je suis aussi confronté à un problème pour
redimensionner une partition du DomU malgré un lvextend. Même à
l'intérieur du DomU, ça ne marche pas bien qu'il voie l'espace libre.
Comment ça ?
Mais c'est sans doute un peu HS ici.
Bah, pourquoi ?
le lvextend marche correctement. Après redémarrage, le DomU voit bien
l'espace supplémentaire (au départ, le LV ne fait que 9G) et un cfdisk
/dev/hda me montre bien l'espace libre:
## fdisk -l /dev/hda
#
#Disk /dev/hda: 10.7 GB, 10737418240 bytes
#255 heads, 63 sectors/track, 1305 cylinders
#Units = cylinders of 16065 * 512 = 8225280 bytes
#
# Device Boot Start End Blocks Id System
#/dev/hda1 * 1 336 2698888+ 83 Linux
#/dev/hda2 337 1174 6731235 5 Extended
#/dev/hda5 337 381 361431 82 Linux swap /
#Solaris
#/dev/hda6 382 1174 6369741 83 Linux
Mais le resize2fs plante:
## resize2fs /dev/hda6 7G
#resize2fs 1.40-WIP (14-Nov-2006)
#La partition (ou le périphérique) n'a seulement que 1592435 (4k) blocs.
#Vous avez demandé une nouvelle taille de 1835008 blocs.
le lvextend marche correctement. Après redémarrage, le DomU voit bien
l'espace supplémentaire (au départ, le LV ne fait que 9G) et un cfdisk
/dev/hda me montre bien l'espace libre:
## fdisk -l /dev/hda
#
#Disk /dev/hda: 10.7 GB, 10737418240 bytes
#255 heads, 63 sectors/track, 1305 cylinders
#Units = cylinders of 16065 * 512 = 8225280 bytes
#
# Device Boot Start End Blocks Id System
#/dev/hda1 * 1 336 2698888+ 83 Linux
#/dev/hda2 337 1174 6731235 5 Extended
#/dev/hda5 337 381 361431 82 Linux swap /
#Solaris
#/dev/hda6 382 1174 6369741 83 Linux
Mais le resize2fs plante:
## resize2fs /dev/hda6 7G
#resize2fs 1.40-WIP (14-Nov-2006)
#La partition (ou le périphérique) n'a seulement que 1592435 (4k) blocs.
#Vous avez demandé une nouvelle taille de 1835008 blocs.
le lvextend marche correctement. Après redémarrage, le DomU voit bien
l'espace supplémentaire (au départ, le LV ne fait que 9G) et un cfdisk
/dev/hda me montre bien l'espace libre:
## fdisk -l /dev/hda
#
#Disk /dev/hda: 10.7 GB, 10737418240 bytes
#255 heads, 63 sectors/track, 1305 cylinders
#Units = cylinders of 16065 * 512 = 8225280 bytes
#
# Device Boot Start End Blocks Id System
#/dev/hda1 * 1 336 2698888+ 83 Linux
#/dev/hda2 337 1174 6731235 5 Extended
#/dev/hda5 337 381 361431 82 Linux swap /
#Solaris
#/dev/hda6 382 1174 6369741 83 Linux
Mais le resize2fs plante:
## resize2fs /dev/hda6 7G
#resize2fs 1.40-WIP (14-Nov-2006)
#La partition (ou le périphérique) n'a seulement que 1592435 (4k) blocs.
#Vous avez demandé une nouvelle taille de 1835008 blocs.