Migrate PM to VM 1.2.0

[JDnoble18]

@george1421
I got this when i entered: showmount -e <ip_address_fog_server>
/images/dev *
/images *

[george1421]

OK rereading your OP multiple times, the first thing you need to get settled is the database export / import. You need to get the settings and passwords into your new system. Without the database the rest of the bits are pointless.

If you are running fog 1.2.0 or a trunk release then there is a built in function to export the configuration from within the gui and then import into your new server. There is no need to use the spiceworks method. That is for the 0.3.x and older release.

GO into the Fog Configuration and select the Configuration Save option that will download the fog_backup.sql to your computer, then go to the new server and upload the settings.

[jmeyer]

If you don’t have too much images, here is how I do :

1. install your new server with different IP (old server will still be usable and never think you won’t need to deploy. I did once… 15 computers needed it…)
2. then there is 2 way for images :

• Mount the directory on new server

mkdir <directoryname>
sudo mount -t nfs -o rw <OldFogServerIP>:/images /home/<youruser>/<directoryname>/
cp -r <directoryname>/ Images/

OR

• REPLICATION !!!

Add new server storage in same group as the storage of the old storage under old GUI.
Don’t set new storage as MASTER or… you are dead ! lol
Check logs : /opt/fog/log/fogreplicator.log ou in GUI http://fogserver/fog/management/index.php?node=about&sub=log then “Image Replicator”.

(OR… the most simple, use Winscp ! lol)

For the host :
Export from old server : Report Management -> Host List -> Format CSV
Edit the file to have : “MAC Address (ie: 00:11:22:33:44:55) *”,“Hostname *”,“IP Address”,“Description”,“Image ID”

*These two things can be enough

Don’t leave this line in it.

Import in new FOG server : Host Management -> Import Hosts

You will have to remake images on GUI (unless you play with SQL) but during copy, you can do it.

[JDnoble18]

@george1421 I did this again, it said the import was successful…still no images, no hosts, and no ad settings. It looks like import/exporting might not work?

What exactly does the import/export do?

[Wayne Workman]

@Quazz said:

You need to export the image list. Go to image management, export images, then import them in the VM.

This feature isn’t available in 1.2.0 stable. It’s in FOG Trunk right now (1.3.0 beta).

[Wayne Workman]

@JDnoble18 said:

@george1421 I did this again, it said the import was successful…still no images, no hosts, and no ad settings. It looks like import/exporting might not work?

What exactly does the import/export do?

The import / export feature exportes the ENTIRE databsae - all settings, everything.
the import overwrites all settings, putting in place everything from the import.

[JDnoble18]

@jmeyer What do you mean by remaking images on GUI? Doesn’t import/export take care of this? I’ve already got the images copied over from the old server to the new one, do you suggest deleting the images folder and starting over?

[JDnoble18]

@Wayne-Workman How stable is 1.3.0? Do you think upgrading my original machine would solve my issues when trying to get this new VM going?

[george1421]

@JDnoble18 said:

@jmeyer What do you mean by remaking images on GUI? Doesn’t import/export take care of this? I’ve already got the images copied over from the old server to the new one, do you suggest deleting the images folder and starting over?

OK, just a second here. You did the export using the FOG configuration right. It should have downloaded a config file (fog_backup.sql) right? Of so open that with notepad++ and look at it. You will see database drops and creates, but there should also be insert into lines. This is placing your data back into the new FOG server. The images and snapin files are different but you should be able to copy the database no problem.

… Just thinking. I wonder if you need to restart the fog service so that it sees the updated data? I’m not sure how much fog caches in memory.

[JDnoble18]

@george1421 I’ve restarted the server several times switching between the old and the new (same IP) so I don’t think that would be it.

I did open the sql file yesterday and saw things that referred to my old install. I am just confused on what it does export and what it does not.

Right now on my new install, after I import the database, I still get empty boxes in the Fog Configuration > Fog Settings > AD Defaults page.

Is database import/export supposed to copy these settings?

On a different note: Are you suggesting that I just need to record the images page from my old server and mimic these images in the new install? If I do this and the files are there then it should work I assume?

[george1421]

This is very, very strange everything should come across except for the physical media. I guess we need to check the apache error log. If you were on rhel it would be /var/log/httpd/error_log. Try the data import and then right away tail the error log and see if the import threw a silent error.

[JJ Fullmer]

Assuming that your original is still up and running, you could try doing a manual database dump and import. This is essentially what the gui is doing so that you don’t have to worry about the command line aspects, but it doesn’t

In the command line on the original server, assuming you went with the default blank password…

mysqldump -u root fog > /home/fog/fog.sql

Then open up winscp, filezilla, cyberduck, or whatever ftp client you prefer (or just use scp in command line to copy straight to the vm) and download the fog.sql file you created.

Then in the new vm server put the fog.sql file in /home/fog and then run this command

mysql -u root fog < /home/fog/fog.sql

And that should take care of it.

Alternatively, especially if it looks like the gui export is working, you can just use the downloaded file from the gui for the second part there.

Hope that helps

[JDnoble18]

Thanks for all your help guys! I really appreciate it!

I went ahead and manually entered all my images info.

I copied down all the settings in the fog settings page in preparation to enter it all manually.

I sent one image successfully, just need to make sure hostname changer is working ok.

I will work more on it Monday. Thanks again for all your help!

[Wayne Workman]

I’m convinced something about the import/export isn’t working right.

It could be SELinux preventing it, could be firewall also.

[Wayne Workman]

@JDnoble18 said:

I am having trouble migrating to a VM.

This thread has given me the idea to create a migration article. We already have an article for changing the IP address of a FOG Server (in the works). In my opinion, that should just be a sub-section. There should be another section in the same article that talks about moving images and other data over to another server.

There are a few ways it can be done - you could do a FULL DB backup - but any problems you have will be migrated too. Or you could do just images,groups,and hosts (in that exact order).

Migrating the actual image data is quite trivial. There are three ways to do that. One is NFS, two is lftp, three is Samba. I’ve written a Samba installation script configured specifically for installing onto a pre-existing FOG Server, it can be found here: https://sourceforge.net/p/samba-for-fog/svn/HEAD/tree/

Tagging this idea for addition to the #wiki in the future.

[george1421]

@Wayne-Workman said:

This thread has given me the idea to create a migration article. We already have an article for changing the IP address of a FOG Server (in the works). In my opinion, that should just be a sub-section. There should be another section in the same article that talks about moving images and other data over to another server.

The one thing you have to be aware of when you migrate, you have to have the same version of FOG on both sides of the migration. For example if you try to migrate from 1.2.0 stable to 1.2.0 stable, you are pretty assured that the data will migrate without issue. But if you try to migrate from 0.32 to 1.2.0 the migration will fail without question. The same holds true if you try to migrate from 1.2.0 stable to 1.2.0 trunk 5676. (understand this is only used to prove a point). The database has changed quite a bit from 1.2.0 to any one of the trunk builds.

In the case of the OP, I think we need to look into why the database is not exporting and importing as expected. Something is not right here. At the very least we can use the process outlined by Arrowhead-IT to migrate the data. But I have a strong belief that this should be done from within the GUI to keep people out of the underlying OS whenever possible.

[Tom Elliott]

@george1421 and all I’m just guessing as to the problem as error logs would go a much longer way. First my guess is the issue is not the import directly, but rather the filesize upload limit set by php. In trunk builds I set the values dealing the post max filesize and Max upload size to a fairly decent 100meg limit. However, on 1.2 and earlier this value was left untouched. The post max filesize is defaulted to 8meg and the upload filesize is defaulted to 2meg. My guess is the upload failed because the size of the sql file is larger than the 2meg limit. The post max limits the number of files ( so 4 2meg files) allowed to upload and their combined size.

[george1421]

@Tom-Elliott You know I’ve been using the trunk version for so long I forgot all about the default file size limitation/setting in php. When I did the import / export test on the 1.2.0 instance I spun up so I could help with 1.2.0 questions. I downloaded, deleted a host reference and uploaded the saved copy and the host came back. But this system only has 2 images and 5 hosts. So the exported database wasn’t very big at all. If the OP has many systems or images I could see how it might reject the import as you stated. Good catch, I think you are spot on.

[Wayne Workman]

@george1421 said:

The one thing you have to be aware of when you migrate, you have to have the same version of FOG on both sides of the migration. For example if you try to migrate from 1.2.0 stable to 1.2.0 stable, you are pretty assured that the data will migrate without issue. But if you try to migrate from 0.32 to 1.2.0 the migration will fail without question. The same holds true if you try to migrate from 1.2.0 stable to 1.2.0 trunk 5676. (understand this is only used to prove a point). The database has changed quite a bit from 1.2.0 to any one of the trunk builds.

I know. I intend to cover this.

In the case of the OP, I think we need to look into why the database is not exporting and importing as expected. Something is not right here. At the very least we can use the process outlined by Arrowhead-IT to migrate the data. But I have a strong belief that this should be done from within the GUI to keep people out of the underlying OS whenever possible.

I’m talking about a total migration. Leaving one OS and going to another, and taking your data, certs, and settings with you. You can’t avoid interacting with the OS for this, if you have many hosts and rely on FOG to do many things you simply cannot abandon your certs and CA now.

[MRCUR]

@Wayne-Workman Have you gotten anywhere on a Wiki article on this topic? I found this thread while looking for the best and most up to date info on doing a FOG server migration. I’ve been looking for the best option to migrate from an existing Ubuntu VM running trunk to a new Ubuntu VM running trunk but don’t want to break anything given FOG runs its own CA now.