# Moving live system to xen machine



## jhite (Oct 1, 2012)

I'm attempting to move an old physical 6.3 email server to a xen host before doing an extensive upgrade. I've already got the same version of FreeBSD installed on xen and running. I'm not looking for a full clone necessarily. I have two systems that boot. I need to move email, user accounts, websites, and that's about it. /var and /usr are on seperate disks so I've already done an initial rsync of those directories and will do a final rsync before I make the switch. The server is physically located... well not near any or my other equipment. 
I was wondering if anyone could tell me what else to sync or what NOT to sync to make this happen. I know certain system files don't need to be copied becuase they would just break it. Like I said, both servers are running in their respective locations. I need to get the users moved from one to the other with little more than a few hours down time when I do the final sync. 
So if anyone can help me with which directories to copy and which to ignore that would be great.


----------



## mix_room (Oct 2, 2012)

6.3 is EOL, is there any particular reason that you installed it?


----------



## SirDice (Oct 2, 2012)

jhite said:
			
		

> I'm not looking for a full clone necessarily.


Good. Migrate to a supported version. 

FreeBSD 6.3 has been End-of-Life since January 2010 and contains quite a number of security issues.


----------



## jhite (Oct 2, 2012)

you both very clearly missed the first sentence didn't you... I'm trying to move an OLD server off it's physical hardware to xen before I start the major upgrade.


----------



## SirDice (Oct 2, 2012)

jhite said:
			
		

> I'm trying to move an OLD server off it's physical hardware to xen before I start the major upgrade.


Why not leave the old server as-is and migrate directly?


----------



## jhite (Oct 2, 2012)

because it's old...
and it's been giving me problems....
and I don't want to do much more than copy it and shut it down...

Why must I explain mysefl to you people? Is it so hard to answer the question... I'm not a FreeBSD guy... my boss skipped town on us and now I've got to deal with this thing... I need help. If you don't want to help... stfu I guess.


----------



## jhite (Oct 2, 2012)

I pretty much already got it... but now i see why more people dont use freebsd. Its not the os thats the problem. Its the freebsd community. How hard is it to answer a simple question? You people dont have anything other than "why" to say.


----------



## wblock@ (Oct 2, 2012)

Being rude to the people trying to help you does not usually get good results.  But hey, your choice, let's see how it plays out.


----------



## jhite (Oct 2, 2012)

wblock@ said:
			
		

> Being rude to the people trying to help you does not usually get good results.  But hey, your choice, let's see how it plays out.



Who tried to help? All I got was do something else with no instruction or direction at all. Not one single person came anywhere near answering which directories I need and which to skip. Nobody said hey be sure to exclude /etc/fstab or you'll bork your boot. Actually, there wasn't a single / in any reply yet. So maybe theres a reading comprehension problem around here. 
I won't have to wait very long to see how it works out. I got it figured out with some help from a linux board. Bind was the only program to throw an error yet and I don't even need bind on there. All the users and files are there. Webmail and address books are there. Websites are there. No thanks to this forum though. But maybe I missed something. So if you'd like a shot at redemption feel free to answer my original question. 

And I do have second question if anybody wants to make me eat my words twice. So and show just how helpful this community can be. How do I go about getting this thing upgraded once I get it moved. Like I said before I'm not a FreeBSD guy. This server is my only experience with it. So I don't really know where to start with that. 

Go on, show me I'm wrong.


----------



## jhite (Oct 2, 2012)

Sorry for the typos. Android dropped some words apparently.


----------



## SirDice (Oct 2, 2012)

Start with an empty (and up to date) server and move the data from the old to the new. Although it's possible I'd advise against doing an in-place upgrade.


----------



## jhite (Oct 2, 2012)

Thank you sir nice. 
Is that really safe? To go from 6.3 to 9 or whatever is current? Will that break any programs or configs?
My plan is to redo this server. It will not be staying as configured. Right now its set up for mbox and we want maildir. Among other things. Thats another reason I want it on the xen machine. I have bandwidth issues and the new server is going on the xenserver. Thats why I want to migrate this old server there. It will make the next step in my process go much faster and smoother. 

I'm dealing with physical location issues, bandwidth issues, and old hardware and software. I'm perfectly aware that this is less than ideal. But I'm trying to correct it. And this server is a live production email server so I can't have days of downtime physically moving the server.


----------



## SirDice (Oct 2, 2012)

jhite said:
			
		

> Is that really safe? To go from 6.3 to 9 or whatever is current? Will that break any programs or configs?


I never said it was safe, I said I'd advise against it. Yes, it will break everything, you will have to rebuild _all_ ports. Which is one of the reasons why I more or less suggested leaving the old server as-is (so it still functions) and only moving the data to a new server.


----------



## chatwizrd (Oct 2, 2012)

I think they are concerned that you are installing 6.3 FreeBSD on the xen server. Why don't you just install a newer version of FreeBSD 9.0, 8.3 or 9.1-PRERELEASE on the xen server. Then rsync over the files you need and see how things run. You might have to reinstall all the mail software, so it is compiled for the new version of FreeBSD, but it usually doesn't take that long.


----------



## jhite (Oct 2, 2012)

Ok, I smell what you're stepping in. My thing is that its going to be a LOT easier for me to do the part you're talking about after I get the old server migrated. Right now I need the least likely to get broken minimal downtime. I do appreciate your concerns for my security, but you're moving faster than I'm able to in a FreeBSD world. As it is I'm already on 6.3 and if I don't get it migrated that will never change. And I've already got 6.3 booted on xen. Really I've done the initial migration already and it boots so I'm doing a lot better than I thought I'd be right now. But I'd still appreciate any insights anyone does have on that specifically. I may have missed something, or worse accidentally copied something I shouldn't have. So in short, I do plan to get current, but I'd feel a lot better about it if I was going from xenoldserver to xencurrentserver than oldbustedserver to currentxenserver.


----------



## AlexJ (Oct 2, 2012)

I guess I got your situation 

read this Backup and Restore Handbook
and this how-to Backup Options For FreeBSD
then create backup with /sbin/dump on original server

Mount Virtual CD on XEN with mfsBSD and boot from it, then do restore (/sbin/restore) of your backup.

Unmount virtual CD and let XEN to boot your live server. (Do not forget to shutdown physical server and dont forget to change DNS settings that point to new location of your mail server)


----------



## jhite (Oct 2, 2012)

Awesome. Thank you thank you. I will have to alter some of that becuase i actually have to change some things anyway. The ip for instance. Theres no way i can use the current ip. Different subnet, different location. But i've already got the dns TTL turned way down. I doubt if theres enough space for a backup locally either. But this info helps all the same.


----------



## wblock@ (Oct 2, 2012)

jhite said:
			
		

> Who tried to help? All I got was do something else with no instruction or direction at all.



Two volunteers tried to help you.  You did not recognize that as help, instead telling them and everyone else, "stfu I guess".



> Not one single person came anywhere near answering which directories I need and which to skip. Nobody said hey be sure to exclude /etc/fstab or you'll bork your boot. Actually, there wasn't a single / in any reply yet. So maybe theres a reading comprehension problem around here.



Maybe they were reluctant to help you screw up.  They don't seem reluctant any more.



> And I do have second question if anybody wants to make me eat my words twice. So and show just how helpful this community can be.



Is that an attitude adjustment, an apology, or "This food is terrible, and the portions are too small"?


----------



## jhite (Oct 2, 2012)

wblock@ said:
			
		

> Is that an attitude adjustment, an apology, or "This food is terrible, and the portions are too small"?




I don't think its any of those things. I'd call it twice the opportunity for redemption. It's not very hard to just say "all you need is x, y, and z. But you really should consider doing this instead."
that way its helpful and you can feel good about yourself.


----------



## phoenix (Oct 2, 2012)

The best migration process is:

Install 9.0 into a Xen VM.
Install the software that you want to use.
Migrate data over from the old server.
Turn off the old server.

Doing anything else will be pointless, full of unseen pitfalls, will take longer, will cause all kinds of grief, and will just lead to frustration, gnashing of teeth, tearing of sackcloth, and smearing of ashes.

You *do not* want to "migrate the old server directly into a VM" and then try to upgrade it.  You are mixing too many things (new hardware, in-place OS upgrades, in-place port upgrades, data migration).

Do one thing at a time (install new OS on new hardware; install new software; migrate data).

Note:  this is exactly what everyone has been telling you from the get-go.  And there's a very good reason everyone has been saying this from the get-go:  you do not want to do this the hard way.


----------



## jhite (Oct 2, 2012)

Here's what i've done...

Installed same OS on new hardware (xen). Migrate data and programs. You all seemed to be the most concerned with the software right now. If that was my main concern i'd be right there with you. But, that is not my main concern. My concerns are with the old hardware thats been giving me problems. It really could fail at any time. The last reboots have not gone through without human intervention. The poorly copied xen version boots flawlessly every time on the other hand.
To anyone else your points would be valid, but to me they aren't solving my immediate problem. 6.3 itself isnt the only EOL software on that machine. The OS migration isn't going to be as smooth as you all think. If my way takes longer that's fine with me. More uptime i can live with. It's the downtime that i'm concerned with.


----------



## AlexJ (Oct 2, 2012)

jhite said:
			
		

> I doubt if theres enough space for a backup locally either.



You don't need to backup it locally on an old server. You can backup it up to any remote server/workstation that can runs SSH.
Just mount old 6.3 machine remote folder over SHH(google how to setup sshfs. It is in /usr/ports/sysutils/fusefs-sshfs) and tell "dump" to keep backup files locally on your computer instead of on an old server.


----------



## AlexJ (Oct 2, 2012)

wblock@ said:
			
		

> Maybe they were reluctant to help you screw up.  They don't seem reluctant any more.



I guess it is a stone to my yard 

A couple of year ago a had an emergency situation on a job site and while I drove to that job site, I got flat tire. When I was towed to a nearest tireshop, tireshop's guys start telling me that I got a hole on a side(which is very questinable) and they will not repair it becouse it is dangerous, but "strongly advise to buy from them new tire".
The only problem - that they didnt have exact same size of tire in the shop as mine and since they heard as I talk on a phone about emergency they offer me "to replace all 4 tires"!!!
By the way, it was a brand new tires, just a few week used.
_Of course - it is a best solution, I agree on that..._
While I walked out outside to free up all accumulated swearing words, one man ask for attention and told me that in a couple of block there is car-shop "Murray's Auto Parts" where I can get self repair kit to fix my tire.
I walked there and fix my tire in 20 minutes(include walking round-trip). When I back home I put this "kinda dangerous" tire on my daughter's car because she drives a car only to a college over roads where speed doesn't exceed 35 miles/hour and located in a few miles from our home.
And funny story ended up that this "dangerous" tire still working till today... in the same way as FreeBSD servers that still run 4.4 version just because nobody want to pay for upgrade. (I even know a network where still working SCO-Linux  )

The guy clearly tell everybody 





> "I need to get the users moved from one to the other with little more than a few hours down time when I do the final sync."


Since he is asking such questions -  it's clearly that he is relatively new to a unix world, which is means it isn't acceptable to "learn on the fly" on a production server.
I'm not sure that even guru in this tread could do "with little more than a few hours down time" this kinda transition in this time gate if they decide to move from 6.3 to 9.
I don't encourage no one to became rude if they didn't get needed answer (*!!!*) and while I completely agree that this server must be upgraded ASAP, it isn't IMHO an answer to the asked question.


----------



## AlexJ (Oct 3, 2012)

phoenix said:
			
		

> The best migration process is:
> 
> Install 9.0 into a Xen VM.
> Install the software that you want to use.
> ...


What question did you answering ?
I'm disappear... 
I can't see a question about "The Best migration process" but I can see concern about quickest possible and reliable way to move ASAP server from failing hardware with minimum downtime.



			
				phoenix said:
			
		

> Doing anything else will be pointless, full of unseen pitfalls, will take longer, will cause all kinds of grief, and will just lead to frustration, gnashing of teeth, tearing of sackcloth, and smearing of ashes.



I really hope that it's my English and I didnt get something or...

*The guy talking about minimum downtime while migrating from FAILING server!!!*

Do you really think that a way that you guys advising him is much faster in THIS SITUATION (*minimum downtime*) than dump/restore???

If there is an OS 6.3, it's clearly understandable that smpt/pop3/imap is also running on outdated software that will be needed to be updated too.
I don't believe that one can "painlessly, without pitfalls and etc" install new OS, new software (that usually has a lot of changes in configuration files between major versions) and migrate/convert data while moving over network (XEN) some kinda of GBytes of data files.

At least you cant do it faster than dump/restore - for sure!


----------



## jhite (Oct 3, 2012)

AlexJ said:
			
		

> The guy clearly tell everybody
> Since he is asking such questions -  it's clearly that he is relatively new to a unix world, which is means it isn't acceptable to "learn on the fly" on a production server.
> I'm not sure that even guru in this tread could do "with little more than a few hours down time" this kinda transition in this time gate if they decide to move from 6.3 to 9.
> I don't encourage no one to became rude if they didn't get needed answer (*!!!*) and while I completely agree that this server must be upgraded ASAP, it isn't IMHO an answer to the asked question.



I agree... like I said... I'm no FreeBSD guy. Is this a best case scenario... no, far from it. Is anyone else going to do it for me??? Doubt it. Will I pull it off... you can bet on it... or against it... doesn't matter to me. But I'm going to tell you how it goes either way.
Truth be told I've got maybe a day of testing while syncing just to make sure everything works like I expect it to. Then in the middle of the night I'm going to turn off the services needed to effectively shut it down, do a final sync (won't be more than the new emails that have come in since the previous sync), update DNS, and voila. And at that moment in time, FreeBSDers everywhere will shed a tear and not know why. But we'll know.


----------



## jhite (Oct 3, 2012)

PS. When I do "shut it off" I'll start a timer and let you know how long the end users are down. And I'm doing this all remotely.


----------



## AlexJ (Oct 3, 2012)

You can switch DNS settings(change IP) when you start moving data because it also take a time (usually 2-6 hours, so it's also downtime).
You can do moving stuff by IP only, but mail server will need correct pointers from DNS when it start working. By the way, usually you can't control reverse IP by yourself, so don't forget to call XEN hosting and ask them to assign correct reverse IP in DNS since most email servers rejecting connections from IPs that has incorrect or absent reverse IP.


----------



## jhite (Oct 3, 2012)

apache, openwebmail, mailman, bind, pop, and smtp are all functioning. Users exist, their files exist (mostly), and their email will be resynced before the final switchover. If I only do the rsync once a day it seems to take about 3 hours. So if I run it once right before the shutdown it should go pretty quickly since not much will have changed. I might even be able to get it going in less than my "few hours" time frame.


----------



## jhite (Oct 3, 2012)

AlexJ said:
			
		

> You can switch DNS settings(change IP) when you start moving data because it also take a time (usually 2-6 hours, so it's also downtime).
> You can do moving stuff by IP only, but mail server will need correct pointers from DNS when it start working. By the way, usually you can't control reverse IP by yourself, so don't forget to call XEN hosting and ask them to assign correct reverse IP in DNS since most email servers rejecting connections from IPs that has incorrect or absent reverse IP.



I've got the DNS TTL turned down to 5 minutes on that server right now. So the change over there should happen long before the final sync finishes. Honestly though, I hadn't thought about the reverse DNS entry yet. Luckily, I am the DNS and XEN host so I don't have to deal with any third parties. BTW, I've been saying xen all along but in truth it's Cirtix XenServer.

And for those wondering how it is possible this person who obviously should not be doing this is responsible for it... it's simple... if nobody else in my company can do something it becomes my job. I got tasked with this email server and luckily I also got tasked with the new XenServer hardware.


----------



## jhite (Oct 6, 2012)

I told you I'd let you know how it went. downtime was 4 hours 20 minutes. Everything's up, end users were mostly assleep so none have even noticed that have bothers to speak up about it. Thanks for that help... it went swell.


----------



## AlexJ (Oct 6, 2012)

I glad that you switched it relatively painlessly. 


> if nobody else in my company can do something it becomes my job


That is exactly what I thought...



> So the change over there should happen long before the final sync finishes


Kinda... most DNS propagate change pretty quickly around the globe but some synchronized once in 6 hours, so it depend what DNS server you query.
To be make sure that your users can reach your server, you need to query outlying their provider DNS servers

```
dig @far.dns.server your.server.com any
```

If you would have a time, take previous advises about moving to latest FreeBSD in account, it was advised with the good reason.


----------



## jhite (Oct 6, 2012)

That's the plan... at least now I have snapshots, bandwidth, and piece of mind. The last one being the most important. 
This server has to go to maildir from mbox, LDAP from passwd, new webmail client, etc. The old one doesn't have quotas turned on at all so some mailboxes are quite ridiculous. There's plenty to get configured now but it will go alot smoother from here I think.


----------



## jhite (Oct 6, 2012)

AlexJ said:
			
		

> Kinda... most DNS propagate change pretty quickly around the globe but some synchronized once in 6 hours, so it depend what DNS server you query.
> To be make sure that your users can reach your server, you need to query outlying their provider DNS servers
> 
> ```
> ...




I actually had the TTL on that zone turned down to 5 minutes. Everything else is a cname back to it. So every 5 minutes any servers that have cached information would regard it as expired and recheck. I'm on a different ISP and I actually had to go into my /etc/hosts file and put in the server and address there because I switched it over too soon.


----------



## kpa (Oct 6, 2012)

AlexJ said:
			
		

> Kinda... most DNS propagate change pretty quickly around the globe but some synchronized once in 6 hours, so it depend what DNS server you query.



DNS doesn't do any kind of active synchronisation either way by default. The existing records just go stale and are deleted when their TTL drops to zero. Only when the records are requested again the new versions of the records get fetched from the authoritative servers. Some resolvers can be configured to automatically refresh the records in the cache when their TTL is getting near zero but it's not a common practise because it can be quite expensive with a large cache.


----------



## AlexJ (Oct 8, 2012)

Yes, sure, you're absolutely technically right. I missed the point about 





> I am the DNS and XEN host so I don't have to deal with any third parties.


 but some VPS/KVM/XEN providers changing DNS settings manually(even if they have web control panel), so I meant human's delay factor, not a DNS TTL. I'm sorry, for confusion.


----------

