<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><div><div>Hi!</div><div><br></div><div>I managed to move the zone "z2" to server "node2" from server "node1", with zonecfg export, and exporting/importing the zonepool2 on an external LUN.</div><div><br></div><div>A rather smooth and easy process, actually, and I can have the LUN visible for both servers without fear, because zfs will not import anything(my zone LUN) if I don't manually import it.</div><div><br></div><div>With some efficient handling, the relocation process can probably be done in 2 minutes, from halt to up and running</div><div><br></div><div>The zone boots and runs, but as you see, it warns for that the vnic2 may not be present or plumbed.</div><div><br></div><div>It is present, though, but I didn't know that it had to be plumbed, is it so?</div><div><br></div><div>When I originally installed the zone I didn't have to plumb anything, the network was working fine an no warnings. Why now?</div><div><br></div><div><br></div><div><br></div><div>root@node2:/# zoneadm -z z2 attach</div><div>WARNING: skipping network interface 'vnic2' which may not be present/plumbed in the global zone.</div><div>Log File: /var/tmp/z2.attach_log.qQaOZn</div><div>               Attach Path: /zonepool2/z2/root</div><div>        Attach ZFS Dataset: zonepool2/z2/ROOT/zbe</div><div><br></div><div>                Installing: Using pre-existing data in zonepath</div><div>       Global zone version: entire@11,5.11-0.151004:20121023T161636Z</div><div>   Non-Global zone version: entire@11,5.11-0.151004:20121023T161636Z</div><div>                     Cache: Using /var/pkg/publisher.</div><div>  Updating non-global zone: Output follows</div><div>No updates necessary for this image.</div><div><br></div><div>                    Result: Attach Succeeded.</div><div>root@node2:/# zoneadm -z z2 boot  </div><div>WARNING: skipping network interface 'vnic2' which may not be present/plumbed in the global zone.</div><div>root@node2:/# zoneadm list -vi</div><div>  ID NAME             STATUS     PATH                           BRAND    IP    </div><div>   0 global           running    /                              ipkg     shared</div><div>   1 z2               running    /zonepool2/z2                  ipkg     shared</div></div><div><br></div><div><br></div><div><div>root@node2:/# dladm show-vnic   </div><div>LINK         OVER         SPEED  MACADDRESS        MACADDRTYPE         VID</div><div>vnic0        bnx0         1000   2:8:20:7:e3:20    random              0</div><div>vnic1        bnx0         1000   2:8:20:bf:c6:b1   random              0</div><div>vnic2        bnx0         1000   2:8:20:e7:b0:b2   random              0</div><div>root@node2:/# </div></div><div><br></div><div><br></div><div>As I said earlier, I will put up the whole process on the wiki, as soon as I got all the details going right....</div><div><br></div><div>Rgrds Johan</div><br><br><font color="#990099">-----Eric Sproul <esproul@omniti.com> skrev: -----</font><div style="padding-left:5px;"><div style="padding-right:0px;padding-left:5px;border-left:solid black 2px;">Till: Johan Kragsterman <johan.kragsterman@capvert.se><br>Från: Eric Sproul <esproul@omniti.com><br>Datum: 2012.12.17 17:11<br>Kopia: omnios-discuss <omnios-discuss@lists.omniti.com><br>Ärende: Re: [OmniOS-discuss] Ang: add rootzpool for zones<br><br><div><font face="Courier New,Courier,monospace" size="3">On Mon, Dec 17, 2012 at 10:59 AM, Johan Kragsterman<br><johan.kragsterman@capvert.se> wrote:<br>>  I suppose you guys have some influense there, about what's going to be<br>> included or not...?<br><br>Since Oracle's additions to Solaris 11 are not open-source, the only<br>way to implement this feature would be a completely separate<br>implementation; "from scratch", as it were.  If someone really wants<br>it, and they have the skill to pull it off, then maybe it will happen.<br> Such is the way of open source. :)<br><br>><br>>  So, if I do not have this feature, could I just install a zone on a<br>> dedicated zpool(like set zonepath=/zonepool1/zone1, where zonepool1 is a<br>> fibre channel LUN), detach it, and then try to attach it in another host?<br>><br>>  I've allready done the first, installed it to a LUN, but not yet tried to<br>> move it.<br>><br>>  If you can provide me with some directions here, I will do this in my SAN<br>> lab, and document it on the OmniOS wiki.<br><br>Zones are lightweight virtualization, so they have deeper dependencies<br>on the host system than do hardware-virtualized solutions.  This makes<br>them trickier to move between hosts, but with some discipline it can<br>be done.<br><br>The source and destination hosts must be running the same OS version.<br>This should both match both between the hosts and between the<br>destination host and the non-global zone being moved, but does not<br>have to.  An upgrade-on-attach procedure is used to compare the<br>attaching zone's packages with the host system, and will attempt to<br>synchronize them.<br><br>A quick summary of the procedure is that you shut down the zone on the<br>source system and detach it (zoneadm -z <zonename> detach).  You<br>relocate the zone's storage to the new host, which in your case is to<br>move the FC LUN.  Then you copy the zone configuration from the source<br>host to the destination host (zonecfg -z <zonename> export -f <file>,<br>then zonecfg -z <zonename> -f <file>).  At this point you have a<br>configured zone on the new host, and you attach with upgrade by doing<br>'zoneadm -z <zonename> attach -u'.  You'll see output on the attach<br>operation's progress and whether it succeeds or not.<br><br>><br>> By the way, it is not much discussions about zones here, is it?<br><br>They tend to "just work".  :)<br><br>Eric<br></font></div></div></div><div></div></font>