Oops, I left my kernel zone configuration behind!

Most people use boot environments to move in one direction.  A system starts with an initial installation and from time to time new boot environments are created - typically as a result of pkg update - and then the new BE is booted.  This post is of little interest to those people as no hackery is needed.  This post is about some mild hackery.

During development, I commonly test different scenarios across multiple boot environments.  Many times, those tests aren't related to the act of configuring or installing zone and I so it's kinda handy to avoid the effort involved of zone configuration and installation.  A somewhat common order of operations is like the following:

# beadm create -e golden -a test1
# reboot

Once the system is running in the test1 BE, I install a kernel zone.

# zonecfg -z a178 create -t SYSsolaris-kz
# zoneadm -z a178 install

Time passes, and I do all kinds of stuff to the test1 boot environment and want to test other scenarios in a clean boot environment.  So then I create a new one from my golden BE and reboot into it.

# beadm create -e golden -a test2
# reboot

Since the test2 BE was created from the golden BE, it doesn't have the configuration for the kernel zone that I configured and installed.  Getting that zone over to the test2 BE is pretty easy.  My test1 BE is really known as s11fixes-2.

root@vzl-212:~# beadm mount s11fixes-2 /mnt
root@vzl-212:~# zonecfg -R /mnt -z a178 export | zonecfg -z a178 -f -
root@vzl-212:~# beadm unmount s11fixes-2
root@vzl-212:~# zoneadm -z a178 attach
root@vzl-212:~# zoneadm -z a178 boot

On the face of it, it would seem as though it would have been easier to just use zonecfg -z a178 create -t SYSolaris-kz within the test2 BE to get the new configuration over.  That would almost work, but it would have left behind the encryption key required for access to host data and any suspend image.  See solaris-kz(5) for more info on host data.  I very commonly have more complex configurations that contain many storage URIs and non-default resource controls.  Retyping them would be rather tedious.

Comments:

I think I missed you where right after the zone configuration a178 configuration in vzl-212 and before the "attach".
How was zone stuff copied from test1 to test2?

Thanks in advance.

Posted by Carlos Azevedo on June 03, 2014 at 09:37 AM CDT #

Carlos,

This line:

# zonecfg -R /mnt -z a178 export | zonecfg -z a178 -f -

copies the zone configuration from the old boot environment (s11fixes-2) into the current boot environment. That is, "zonecfg -R /mnt -z a178 export" writes the configuration of zone a178 in the s11fixes-2 boot environment to stdout. "zonecfg -z a178 -f -" reads the configuration from stdin and configures the zone a178 in the current BE.

Posted by Mike Gerdts on June 03, 2014 at 10:36 AM CDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Contributors:

  • Mike Gerdts - Principal Software Engineer, Solaris Virtualization
  • More coming soon!

Search

Categories
Archives
« April 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  
       
Today