HOWTO: migrating jails with theBrig

[birnbacs]

I have two XigmaNAS servers, one of which is productive while the other one is for development and hot standby. On both machines I host jails in which a bunch of applications are running. Basically it's an application server in a jail running on each box.

My major reasons for using jails is the ability to replace one with another across machines if required, so I can
* scale hardware
* develop software
* fail over and fail back
* load balance
as required. Here is how I migrate jails between machines with theBrig.

Compared to other jail managers like iocage, theBrig is somewhat rudimentary software. On the other hand it has the advantage to come as an extension to XigmaNAS. As such it neatly ligns up with the other GUI controls and does not require a "full" XigmaNAS installation. This was important to me as I chose an embedded "root on zfs" install where the boot medium is mirrored.

In short, I did this:

• move the jail's files from server A to server B (see below)
• create a fresh jail with theBrig on B
• pull theBrig's XML configuration from TheBrig > Maintenance > Backup/Restore
• change the name and location of the fresh jail to the imported one
• feed back the edited XML file to theBrig
• refresh the theBrig page and click on Start

In my case, the source jail was not a dataset but was stored on the file system; I simply used

Code: Select all

tar -cvf myjail.tar myjail

The entire jail came to about 12GB of space and tarring took more than 30 minutes on good old A.

The fresh jail was created as a dataset. So another dataset for the migrated jail was created with

Code: Select all

zfs create dataset <mypool>/<mydataset>

The tarball was unpacked into this dataset with

Code: Select all

tar -xvf myjail.tar

As this worked, the given procedure should work in other combinations as well, e.g. dataset -> dataset, fileset -> fileset or dataset -> fileset.

The actual files of the freshly created jail can then be removed. If you created the fresh jail as a dataset,

Code: Select all

zfs list

will show where it is, so you can destroy it with

Code: Select all

zfs destroy <mypool>/<freshdataset>

Needless to say, this is a dangerous operation and care should be taken not to destroy the wrong dataset.

If the jail will not start after a few seconds, you may want to check

Code: Select all

<thebrig installation location>/thebrig.log

for errors. After the jail came up, you can change into it with

Code: Select all

jexec <myjail> sh

in a terminal on B. Personally, I prefer to use

Code: Select all

jexec <myjail> login <some non-privileged user>

The commands may have to be issued under sudo.

Once inside the migrated jail you want to make sure local services are aware of the current IP address you gave to the fresh jail.

In my case A runs XigmaNAS 11.2.0.4 while B runs XigmaNAS 12.0.0.4. The latter comes with the brandnew version 12 of FreeBSD so I expected problems -- and was surprised to not get any. Right now I am working on updating the jail with freebsd-update.

[cookiemonster]

Good of you to post this. I've bookmarked it as it will come in handy. With thebrig pretty much without development, I've always put off upgrading major releases. I've had to recreate from scratch and re-live the pain every time.

[birnbacs]

Please note that this is ongoing work. I am still encountering quirks here and there. But yes, it is basically working
BTW, I could not bsd-upgrade my jail so far. It seems a good move to sync BSD versions on source and sink before migrating a jail.

[birnbacs]

I repeated the process and noted that it is mandatory to have the superuser execute both tar commands. I used sudo for this.

[alexey123]

Hi
TheBrig have tool for archive jails.
User can backup jail before delete it. Just check option at rudimentary config.

Thebrig will create archieved backup into work folder.

Then user can build jail from backup, need just choice backup file instead source.