12:45 a.m.
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/
1:09 a.m.
On Wed, Feb 10, 2016 at 7:45 AM, Nadav Goldin <ngoldin(a)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(a)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)
2:02 a.m.
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(a)redhat.com
RHEV-CI Team
2:04 a.m.
--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:
> 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 =
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(a)redhat.com
RHEV-CI Team
_______________________________________________
Infra mailing list
Infra(a)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(a)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--
2:20 a.m.
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(a)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(a)redhat.com
RHEV-CI Team
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
--
Anton Marchukov
Senior Software Engineer - RHEV CI - Red Hat
2:20 a.m.
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-f...
[2] http://tldp.org/HOWTO/LVM-HOWTO/initdisks.html
[3]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/...
On Wed, Feb 10, 2016 at 11:02 AM, Barak Korren <bkorren(a)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(a)redhat.com
> RHEV-CI Team
>
2:22 a.m.
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(a)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-f...
[2] http://tldp.org/HOWTO/LVM-HOWTO/initdisks.html
[3]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/...
On Wed, Feb 10, 2016 at 11:02 AM, Barak Korren <bkorren(a)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(a)redhat.com
> RHEV-CI Team
>
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
--
Anton Marchukov
Senior Software Engineer - RHEV CI - Red Hat
2:54 a.m.
On 10 February 2016 at 11:22, Anton Marchukov <amarchuk(a)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(a)redhat.com
RHEV-CI Team
5:17 a.m.
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(a)redhat.com> wrote:
On 10 February 2016 at 11:22, Anton Marchukov
<amarchuk(a)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(a)redhat.com
RHEV-CI Team
3009
days inactive
3009
days old
8 comments
5 participants
participants (5)
-
Anton Marchukov -
Barak Korren -
David Caro -
Eyal Edri -
Nadav Goldin