Time to work on a Plan: Moving VM's

[Bruno Miguel Queiros]

Number 2 seems to be the cleanest and least problems solution.

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 at gmail.com> 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 at gmail.com>:
>> 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 at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
> 
> 
> 
> --
> Abdel G. Martínez L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20150806/94787492/attachment.html>