new Jenkins VM in PHX lab
Hi all, I installed yesterday a fresh Jenkins VM in the PHX datacenter at jenkins.phx.ovirt.org running centos 7.2, few details: 1. It is puppetized, but still needs some verification[1], I was able to auto-generate the plugins list from jenkins.ovirt.org into the puppet manifest, so it has exactly the same plugins installed. the concept might also work for future migrations we do between the instances. 2. the jenkins data directory is 500gb configured with lvm and xfs. I was able to do "live" storage incrase by adding a new volume to the LVM group in the following procedure: - created new virtio volume in the VM from phx-engine - fdisk /dev/vdd then: n -> p -> 1 -> enter -> enter -> t -> 8e -> w - vgextend jenkins_lvm /dev/vdd1 - lvextend /dev/mapper/jenkins_lvm-data -L28G - xfs_growfs /dev/mapper/jenkins_lvm-data I was unable to increase the volume size from the engine, and then increase the partition size(only create a new partition on the same volume with the new increased space in the volume), not sure if that is possible. 3. authentication - same as jenkins.ovirt.org for now: self enrol and adding permissions(ping me) 4. there is much more configuration that needs to be done to make it functional, but i guess we can start by testing it :) [1] https://gerrit.ovirt.org/#/c/53309/
On Wed, Feb 10, 2016 at 7:45 AM, Nadav Goldin <ngoldin@redhat.com> wrote:
Hi all, I installed yesterday a fresh Jenkins VM in the PHX datacenter at jenkins.phx.ovirt.org running centos 7.2, few details: 1. It is puppetized, but still needs some verification[1], I was able to auto-generate the plugins list from jenkins.ovirt.org into the puppet manifest, so it has exactly the same plugins installed. the concept might also work for future migrations we do between the instances. 2. the jenkins data directory is 500gb configured with lvm and xfs. I was able to do "live" storage incrase by adding a new volume to the LVM group in the following procedure:
- created new virtio volume in the VM from phx-engine - fdisk /dev/vdd then: n -> p -> 1 -> enter -> enter -> t -> 8e -> w - vgextend jenkins_lvm /dev/vdd1 - lvextend /dev/mapper/jenkins_lvm-data -L28G - xfs_growfs /dev/mapper/jenkins_lvm-data
I was unable to increase the volume size from the engine, and then increase the partition size(only create a new partition on the same volume with the new increased space in the volume), not sure if that is possible.
We need to allocate it enough memory & cpu as well, if the current hypervisors can't support it, we need to move another hypervisor into the production DC.
3. authentication - same as jenkins.ovirt.org for now: self enrol and adding permissions(ping me)
For now might be OK, but we need to think if we want to change it before the migration, SSO will probably take time to implement so I wouldn't block on it.
4. there is much more configuration that needs to be done to make it functional, but i guess we can start by testing it :) [1] https://gerrit.ovirt.org/#/c/53309/
Indeed. one thing we need to make sure it to yamelize all the jobs that are not in yaml yet, before the migration. I also created a ticket [1], so lets continue tracking progress there. [1] https://ovirt-jira.atlassian.net/browse/OVIRT-401
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Eyal Edri Associate Manager EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
able to do "live" storage incrase by adding a new volume to the LVM group in the following procedure:
created new virtio volume in the VM from phx-engine fdisk /dev/vdd then: n -> p -> 1 -> enter -> enter -> t -> 8e -> w vgextend jenkins_lvm /dev/vdd1 lvextend /dev/mapper/jenkins_lvm-data -L28G xfs_growfs /dev/mapper/jenkins_lvm-data
I was unable to increase the volume size from the engine, and then increase the partition size(only create a new partition on the same volume with the new increased space in the volume), not sure if that is possible.
You forgot the 1st thing we told you - "don't create partitions on the disk"... Instead the whole disk '/dev/vdX' should be formatted as a PV, then you can grow it from the engine and then 'pvresize' followed by 'lvresize'. -- Barak Korren bkorren@redhat.com RHEV-CI Team
able to do "live" storage incrase by adding a new volume to the LVM gro= up in the following procedure:
created new virtio volume in the VM from phx-engine fdisk /dev/vdd then: n -> p -> 1 -> enter -> enter -> t -> 8e -> w vgextend jenkins_lvm /dev/vdd1 lvextend /dev/mapper/jenkins_lvm-data -L28G xfs_growfs /dev/mapper/jenkins_lvm-data
I was unable to increase the volume size from the engine, and then incr= ease the partition size(only create a new partition on the same volume with =
--oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 02/10 11:02, Barak Korren wrote: the
new increased space in the volume), not sure if that is possible.
You forgot the 1st thing we told you - "don't create partitions on the di= sk"... Instead the whole disk '/dev/vdX' should be formatted as a PV, then you c= an grow it from the engine and then 'pvresize' followed by 'lvresize'.
If it's puppetized, that's easy to reprovision no?
=20 =20 --=20 Barak Korren bkorren@redhat.com RHEV-CI Team _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605 --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWuv0fAAoJEEBxx+HSYmnDXIIH/2C7uj7Cf/iNI44TxVffzYv0 8DoD9DD7vp/gywHt2OwBupvIe+sOFOsFuFYhzVwKW8EEQBd00H6jZZkeApovTDUj jQ6DpvzOEHu1WH6f/+ac32B4HELDRKZkDfy+hi07JIjP/GtnHba6b03Lu8MN4xMP H0OAditxgPvYLOPzai/F0Q0uOgufcB7MV7j/cia9/gPUTcG81j6LeQLEB7iHxRd/ PlypI/QRiXdfc6V66hX1mk7qCgLCVCS/JQp+r3POSp63xNb/uZscxbPURU+3VMTV 6fQQmzopk38TvYDT1W+2yQbhE9qq9uBSl5cIksAgpammic6Vy7ouuoNC13TuegI= =xgmC -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl--
Hello All. Please check how it is implemented on "resources". We just need to allocate a separate shared disk for storing data and mount it into /var/lib/jenkins. This disk should not have any partitions just be plain /dev/vdb or whatever block device. I think we really do not needed to grow the root file system as once it is puppetized and "data" disk is made sharable it is easy to provision another vm and make it use the same data. Providing we leave enough space in root that should be enough to go I think. To grow that data disk you increase it's size in UI and then do resizefs or whatever tool for your filesystem is and that's it. No downtime and no extra abstractions like LVM or whatever. Even no parameters to resizefs as it determines the block device size itself. Completely error proof. And running "fdisk" is dangerous operation to my opinion as you can easily mess it up. This is my opinion of cause, but resources already uses that schema. On Wed, Feb 10, 2016 at 10:02 AM, Barak Korren <bkorren@redhat.com> wrote:
able to do "live" storage incrase by adding a new volume to the LVM group in the following procedure:
created new virtio volume in the VM from phx-engine fdisk /dev/vdd then: n -> p -> 1 -> enter -> enter -> t -> 8e -> w vgextend jenkins_lvm /dev/vdd1 lvextend /dev/mapper/jenkins_lvm-data -L28G xfs_growfs /dev/mapper/jenkins_lvm-data
I was unable to increase the volume size from the engine, and then increase the partition size(only create a new partition on the same volume with the new increased space in the volume), not sure if that is possible.
You forgot the 1st thing we told you - "don't create partitions on the disk"... Instead the whole disk '/dev/vdX' should be formatted as a PV, then you can grow it from the engine and then 'pvresize' followed by 'lvresize'.
-- Barak Korren bkorren@redhat.com RHEV-CI Team _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Anton Marchukov Senior Software Engineer - RHEV CI - Red Hat
You forgot the 1st thing we told you - "don't create partitions on the disk"... Instead the whole disk '/dev/vdX' should be formatted as a PV, then you can grow it from the engine and then 'pvresize' followed by 'lvresize'.
I didn't forget, I came across [1] which quotes [2] and [3] saying best-practice is to create a partition on the PV:
*Not Recommended*
Using the whole disk as a PV (as opposed to a partition spanning the whole disk) is not recommended because of the management issues it can create. Any other OS that looks at the disk will not recognize the LVM metadata and display the disk as being free, so it is likely it will be overwritten. LVM itself will work fine with whole disk PVs.
although I am no expert in lvm so if we agree its ok, no problem, I'll change it. [1] http://unix.stackexchange.com/questions/76588/what-is-the-best-practice-for-... [2] http://tldp.org/HOWTO/LVM-HOWTO/initdisks.html [3] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm... On Wed, Feb 10, 2016 at 11:02 AM, Barak Korren <bkorren@redhat.com> wrote:
able to do "live" storage incrase by adding a new volume to the LVM group in the following procedure:
created new virtio volume in the VM from phx-engine fdisk /dev/vdd then: n -> p -> 1 -> enter -> enter -> t -> 8e -> w vgextend jenkins_lvm /dev/vdd1 lvextend /dev/mapper/jenkins_lvm-data -L28G xfs_growfs /dev/mapper/jenkins_lvm-data
I was unable to increase the volume size from the engine, and then increase the partition size(only create a new partition on the same volume with the new increased space in the volume), not sure if that is possible.
You forgot the 1st thing we told you - "don't create partitions on the disk"... Instead the whole disk '/dev/vdX' should be formatted as a PV, then you can grow it from the engine and then 'pvresize' followed by 'lvresize'.
-- Barak Korren bkorren@redhat.com RHEV-CI Team
Hello All. Why do we need LVM at all there? It is good when you cannot resize the underlying disk and have to combine it from several hardware ones into one virtual. But here we have "cloud" and disks are already resizeable. Anton. On Wed, Feb 10, 2016 at 10:20 AM, Nadav Goldin <ngoldin@redhat.com> wrote:
You forgot the 1st thing we told you - "don't create partitions on the
disk"... Instead the whole disk '/dev/vdX' should be formatted as a PV, then you can grow it from the engine and then 'pvresize' followed by 'lvresize'.
I didn't forget, I came across [1] which quotes [2] and [3] saying best-practice is to create a partition on the PV:
*Not Recommended*
Using the whole disk as a PV (as opposed to a partition spanning the whole disk) is not recommended because of the management issues it can create. Any other OS that looks at the disk will not recognize the LVM metadata and display the disk as being free, so it is likely it will be overwritten. LVM itself will work fine with whole disk PVs.
although I am no expert in lvm so if we agree its ok, no problem, I'll change it.
[1] http://unix.stackexchange.com/questions/76588/what-is-the-best-practice-for-... [2] http://tldp.org/HOWTO/LVM-HOWTO/initdisks.html [3] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/htm...
On Wed, Feb 10, 2016 at 11:02 AM, Barak Korren <bkorren@redhat.com> wrote:
able to do "live" storage incrase by adding a new volume to the LVM group in the following procedure:
created new virtio volume in the VM from phx-engine fdisk /dev/vdd then: n -> p -> 1 -> enter -> enter -> t -> 8e -> w vgextend jenkins_lvm /dev/vdd1 lvextend /dev/mapper/jenkins_lvm-data -L28G xfs_growfs /dev/mapper/jenkins_lvm-data
I was unable to increase the volume size from the engine, and then increase the partition size(only create a new partition on the same volume with the new increased space in the volume), not sure if that is possible.
You forgot the 1st thing we told you - "don't create partitions on the disk"... Instead the whole disk '/dev/vdX' should be formatted as a PV, then you can grow it from the engine and then 'pvresize' followed by 'lvresize'.
-- Barak Korren bkorren@redhat.com RHEV-CI Team
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Anton Marchukov Senior Software Engineer - RHEV CI - Red Hat
On 10 February 2016 at 11:22, Anton Marchukov <amarchuk@redhat.com> wrote:
Hello All.
Why do we need LVM at all there? It is good when you cannot resize the underlying disk and have to combine it from several hardware ones into one virtual. But here we have "cloud" and disks are already resizeable.
Becasue LVM lets you do snapshots you can mount and copy somewhere else (e.g. to do atomic backups). You cannot do that easily with oVirt disk snapshots ATM. -- Barak Korren bkorren@redhat.com RHEV-CI Team
re-installed and configured it without a partition table on the block device. the updated procedure for increasing the volume size: if there is still available space in the lvm group jenkins_lvm (can be seen using vgdisplay): 1. lvextend /dev/mapper/jenkins_lvm-data -L410G 2. xfs_growfs /dev/mapper/jenkins_lvm-data else: 1. increase volume size in engine-ui 2. pvresize /dev/vdb 3. lvextend /dev/mapper/jenkins_lvm-data -L410G 4. xfs_growfs /dev/mapper/jenkins_lvm-data On Wed, Feb 10, 2016 at 11:54 AM, Barak Korren <bkorren@redhat.com> wrote:
On 10 February 2016 at 11:22, Anton Marchukov <amarchuk@redhat.com> wrote:
Hello All.
Why do we need LVM at all there? It is good when you cannot resize the underlying disk and have to combine it from several hardware ones into one virtual. But here we have "cloud" and disks are already resizeable.
Becasue LVM lets you do snapshots you can mount and copy somewhere else (e.g. to do atomic backups). You cannot do that easily with oVirt disk snapshots ATM.
-- Barak Korren bkorren@redhat.com RHEV-CI Team
participants (5)
-
Anton Marchukov -
Barak Korren -
David Caro -
Eyal Edri -
Nadav Goldin