Migrate PM to VM 1.2.0

[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.

[Wayne Workman]

@MRCUR Thanks for bumping this thread.

Tagging this for the wiki so I don’t forget about it again.

But basically, for 1.3.0 (currently in development):

inside of /opt/fog/snapins/CA you’ll find your CA. This is the important piece that you want to save.

(You might want to copy /opt/fog/snapins/ssl too)

You’d use the web interface to export just your hosts and images. These can both be done from the host management page and the image management page.

Next you want to save your images. There are a large number of ways to do this - but NFS is the most simple as it doesn’t require credentials and the existing FOG server should already have the images exported via NFS.

On the new server, the commands to mount and copy would be:

cd /
mkdir /images
mkdir tempMount
mount x.x.x.x:/images /tempMount
cd /tempMount
cp -R *.* /images
umount /tempMount

However this can also be done recursively with FTP, and can be done with Samba as well. I’ve built a project that installs and configures Samba specifically for a fog server. It’s on sourceforge called “Samba for Fog”.

When you install fog on the new server, just go ahead and install it initially like normal. After it’s installed, you can swap out the CA for the old one. Then you’d run the installer again - this will re-create new certificates for you, based on that CA.

Then you’d import your images FIRST in Image management, and then import your hosts second in host management.

Importing images is a little funny, the ID numbers get re-set to begin at zero. For instance I have several images, all begin in the 30s and up. Re-importing those would reset all the IDs. I’m not sure if it matters at all, honestly. Just something I’ve noticed.

Of course, if your FOG IP changes, then you’ll need to update Option 066 / Next-Server on whatever is doing DHCP. If FOG is doing DHCP, it will configure itself for this. Also, if the IP changes, and you’ve installed the FOG Client using the IP, then all your FOG Clients will stop working (and will need re-installed). If you’ve installed the FOG Client using a FQDN, then all you need to do is update the DNS “A” record for that FQDN to point to the new IP, and make sure your new fog server has the same name as the old one.

The most important bit of advice I can give is don’t blow away your old server. Leave it alone in case disaster strikes. Only decommission it when you’re sure you’re solid.

[MRCUR]

@Wayne-Workman Thanks Wayne. That’s just the info I was looking for.

At this point, is the built-in config export/import not really needed anymore, or has it not been updated to handle the new CA/SSL pieces? I’m fine with your method since I’m not looking to migrate “bad” settings/config info, but I do use the location plugin and I’m not sure your method would move that data over.