I can see all sort of breakage that can happen if using number 1.
Best regards
Em Qui, 6 de Ago, 2015 às 21:52, Abdel G. Martínez L. <abdel.g.martinez.l@xxxxxxxxx> escreveu:
Number 1 is an interesting option but I think number 2 is more feasible in terms of less effort and decrease confusions during the process.Best regards.2015-08-06 14:49 GMT-05:00 Stephen John Smoogen <smooge@xxxxxxxxx>:We have new hardware in to replace some of our 4+ year old IBM x3650's
and need to do so in the next month or so to make sure we have a good
list of hardware to go onto extended warranty this fall.
I would like to come up with a plan of attack on getting them all
moved by September 1st to virthost19->virthost22.
Hardware Server Virtual Machine
virthost05.phx2.fedoraproject.org bastion02.phx2.fedoraproject.org
virthost05.phx2.fedoraproject.org db-fas01.phx2.fedoraproject.org
virthost05.phx2.fedoraproject.org proxy01.phx2.fedoraproject.org
virthost06.phx2.fedoraproject.org ask01.phx2.fedoraproject.org
virthost06.phx2.fedoraproject.org notifs-web02.phx2.fedoraproject.org
virthost07.phx2.fedoraproject.org datagrepper02.phx2.fedoraproject.org
virthost07.phx2.fedoraproject.org elections01.phx2.fedoraproject.org
virthost07.phx2.fedoraproject.org hotness01.phx2.fedoraproject.org
virthost07.phx2.fedoraproject.org nuancier01.phx2.fedoraproject.org
virthost08.phx2.fedoraproject.org darkserver01.phx2.fedoraproject.org
virthost08.phx2.fedoraproject.org ns03.phx2.fedoraproject.org
virthost09.phx2.fedoraproject.org busgateway01.phx2.fedoraproject.org
virthost09.phx2.fedoraproject.org fedocal01.phx2.fedoraproject.org
virthost09.phx2.fedoraproject.org notifs-backend01.phx2.fedoraproject.org
virthost09.phx2.fedoraproject.org nuancier02.phx2.fedoraproject.org
virthost10.phx2.fedoraproject.org bodhi01.stg.phx2.fedoraproject.org
virthost10.phx2.fedoraproject.org bodhi02.stg.phx2.fedoraproject.org
virthost10.phx2.fedoraproject.org fas01.stg.phx2.fedoraproject.org
virthost10.phx2.fedoraproject.org koji01.stg.phx2.fedoraproject.org
virthost10.phx2.fedoraproject.org notifs-web02.stg.phx2.fedoraproject.org
virthost10.phx2.fedoraproject.org summershum01.stg.phx2.fedoraproject.org
There are a couple of ways we do these transitions.
1) Spin up a new virtual machine with an incremented hostname:
Example:
a) check to see which ask systems exist. (ask01, ask02)
b) create a new virtual machine with an incremented number: ask03
c) ansible the system to be clone of ask01
d) either turn off ask01 and rename ask03 to be ask01
OR
d) configure other servers to point to ask03 instead of ask01
e) fix problems as needed
f) shutdown and remove ask01.
2) Move virtual machine to another server.
a) Schedule a downtime
b) Shutdown the server
c) network dd the lvm image to other server.
d) copy over the /etc/libvirt/qemu/___.xml file over to other server.
e) spin up server
f) fix problems as needed
g) remove files from old server
3) If the image is on an iscsi share versus local disks...
a) shutdown the image on server A.
b) copy the xml files over to server B.
c) get libvirt to see them.
d) start the image on server B
e) remove the xml files from server A.
It looks like none of the servers in question are on the iscsi share
so we won't be able to do 3. [Unless there is one or two that are good
candidates to be on the iscsi share... then a variant of 2 would be
used.]
Downtimes except for the fas system will be in the 20 minute range.
The fas database might be 1-3 hours due to a 100 GB image to be copied
over and the usual 'what we have to reboot that because this was down?
WHY?' problems we end up with.
Other plans and ideas can be replied to here.
--
Stephen J Smoogen.
_______________________________________________
infrastructure mailing list
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/infrastructure--Abdel G. Martínez L.
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
