2015年8月26日 星期三

[ Big Data 研究 ] 04 管理 Linux Container 虛擬網路 - Part1

預設虛擬網路架構
對於虛擬系統來說, 網路架構是否正確, 連線功能是否正常, 是攸關整個虛擬系統能否發揮功能的重要關鍵, 即使是 LXC 核心模組也不例外. 但早期的網路系統, 大多利用網路硬體裝置, 如實體的 Router, Switch 等, 來串接各個網路區段的主機, 或是公司內部網路的連結, 除了建置成本昂貴外, 還需要投入不少人力在維護網路硬體設備的運作. 這對於一般中小企業來說, 若要架設一個公司專屬的私有雲, 在經費與人力上, 都是相當沉重的負擔.

若能利用 Linux 原生的虛擬網路, 就可以達到大部分內部私有雲所需要的網路架構. 這不只可以大大減省網路硬體設備的支出, 更可以利用現有 Linux 系統的管理人員, 直接管控系統與網路的運作, 讓架構公司內部的私有雲, 成為一種可能, 且不管是那一套虛擬系統, 只要是運作在 Linux 系統下, 大多會使用 Linux 原生的虛擬網路架構, 當然 Linux Container 也不例外.

Linux 原生的虛擬網路架構, 其實是由 Linux 系統早已存在的虛擬網路元件所組成. 而這些元件包含了 "TUN/TAP 虛擬網路卡", "虛擬 Bridge", "iptables" 與 "dnsmasq". 各個元件在 Linux 原生虛擬網路架構中, 扮演不同的角色, 且每個元件都可以獨立運作, 也可以互相搭配為我們所需的網路架構.

LXC 虛擬網路橋接器及 TUN/TAP 虛擬網路卡
虛擬網路構成元件中的 "虛擬橋接器", 主要負責連接不同的網路系統, "TUN" 和 "TAP" 是以軟體來模擬虛擬網路卡, 就功能來說, "TUN" 是屬於 OSI 的第三層, 也就是網路層, 主要處理 IP 與 Route 封包的傳遞; 而 "TAB" 則是屬於 OSI 網路通訊協定的第二層, 也就是資料連結層, 主要負責實體網路封包的傳遞, 總結一句話 "TUN/TAP" 就是 Ethernet 虛擬網路卡!

雖然在 Linux 系統內要建立 Bridge 網路連線模式看似有些複雜, 但幸運的是 LXC 核心模組已經將這些繁瑣的步驟一次處理完畢, 只需要裝好 LXC 核心模組, 在 Linux 系統中, 就會產生一個 "虛擬橋接器" 了, 這個橋接器可以透過命令 brctl 檢視:


上圖可以觀察到 "lxcbr0" 這個名稱, 這就是安裝好 LXC 核心模組後所產生的 "虛擬橋接器". 而 vethxxx 就是連接到此橋接器的 TUN/TAP 虛擬網路卡. 此虛擬橋接器同時也是 "核心網路卡名稱", 我們可以使用 ip 指令查看 lxcbr0 橋接器的 "網路卡" 資訊:
# ip addr show
...
3: lxcbr0: mtu 1500 qdisc noqueue state UP group default
link/ether fe:3a:9d:76:76:04 brd ff:ff:ff:ff:ff:ff
inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0
valid_lft forever preferred_lft forever
inet6 fe80::3c31:baff:fe76:f07c/64 scope link
valid_lft forever preferred_lft forever
...

LXC 預設 NAT 轉址功能 (iptables)
NAT (Network Address Translation) 轉址功能, 是 iptables (IP 過濾器) 的規則之一, 當 IP 封包往外送時, 會將來源 IP 位址偽裝的一種網路技術. 輸入以下指令來查看 iptables 中的 NAT 規則:
// -t nat: iptables 至少有三個預設的 table (filter, nat, mangle), 這邊指定的 table nat
// -L: 此參數用來列出指定 table 的規則
// -n: 此參數表示不進行 IP 與 Hostname 的反查, 可以提升顯示速度

# iptables -t nat -L -n

從上面訊可以發現實體主機上的 iptables 加入了一筆 "10.0.3.0/24" 的資訊, 而這筆資訊就是透過 iptables 啟動了 NAT 轉址功能, 只要是從 "source" 欄位的 IP 位址等於 "10.0.3.0/24" 發送出去的封包, 都會透過 NAT 轉址的功能, 將虛擬主機的私有 IP 偽裝成外部連結網路的 IP 位址; 而 "destination" 代表的是目的 IP 位址, 此欄位設定值 "! 10.0.3.0/24" 中的驚嘆號, 代表除了 "10.0.3.0/24" 這個 Network ID 之外, 其餘連結外部網路的 IP位址, 都可以透過 NAT 轉址功能順利溝通.
Note.
"MASQUERADE" 的功用是 IP 位址偽裝 (IP Masquerading), 將虛擬主機的私有 IP 偽裝成連結外部網路的 IP 位址.

LXC 預設 DHCP Server 與 DNS Cache Server (dnsmasq)
虛擬網路構成元件中的 "dnsmasq" 是一個輕量級的 "DHCP Server" 及 "DNS Cache Server". 其中 "DHCP Server" 的功能是負責分派 IP 位址; 而 "DNS Cache Server" 則是網域名稱解析伺服器, 負責儲存 Client 端曾經拜訪的網域名稱, 並提供名稱解析的快取功能, 方便 Client 端再次查詢時可以快速回覆網域名稱.

輸入以下指令查看 "dnsmasq" 的設定:
# ps aux | grep dnsmasq
lxc-dns+ 1303 0.0 0.1 28212 2276 ? S Aug23 0:00 dnsmasq -u lxc-dnsmasq --strict-order --bind-interfaces --pid-file=/run/lxc/dnsmasq.pid --conf-file= --listen-address 10.0.3.1 --dhcp-range 10.0.3.2,10.0.3.254 --dhcp-lease-max=253 --dhcp-no-override --except-interface=lo --interface=lxcbr0 --dhcp-leasefile=/var/lib/misc/dnsmasq.lxcbr0.leases --dhcp-authoritative

上面可以觀察到 "dnsmasq" 再啟動時就分別了 "DHCP Server" 與 "DNS Cache Server" 的功能. 設定 "--listen-address 10.0.3.1" 就是 "DHCP Server" 的 IP 位址; 設定 "--dhcp-range 10.0.3.2,10.0.3.254" 說明 DHCP 可以派發的 IP 位址的範圍. 更多的設定說明可以參考 "dnsmasq" 的 man page.

修改預設虛擬網路架構

修改 LXC 核心模組網路設定檔 (lxc-net)
由前面觀察到的預設 LXC 網路架構, 可以透過編輯檔案 /etc/default/lxc-net 進行變更:
# vi /etc/default/lxc-net

接著我們進行如下的修改:
  1. LXC_BRIDGE="lxcbr0"  
  2. LXC_ADDR="10.0.100.1"  
  3. LXC_NETMASK="255.255.255.0"  
  4. LXC_NETWORK="10.0.100.0/24"  
  5. LXC_DHCP_RANGE="10.0.100.200,10.0.100.250"  
  6. LXC_DHCP_MAX="10"  
  7.   
  8. LXC_SHUTDOWN_TIMEOUT=120  
接著停止所有運行的虛擬機, 並使用下面指令重啟 LXC 網路設定:
# service lxc-net restart
lxc-net stop/waiting
lxc-net start/running

# ip addr show lxcbr0
37: lxcbr0: mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether 8a:50:2d:0f:23:08 brd ff:ff:ff:ff:ff:ff
inet 10.0.100.1/24 brd 10.0.100.255 scope global lxcbr0

從上面的輸出可以確認核心網卡的 IP 位址已經修改為我們剛剛設定的 "10.0.100.1/24", 接著可以再確認 dnsmasq 的設定:
# ps aux | grep dnsmasq
lxc-dns+ 27239 0.0 0.1 28212 2320 ? S 07:02 0:00 dnsmasq -u lxc-dnsmasq --strict-order --bind-interfaces --pid-file=/run/lxc/dnsmasq.pid --conf-file= --listen-address 10.0.100.1 --dhcp-range 10.0.100.200,10.0.100.250 --dhcp-lease-max=10 --dhcp-no-override --except-interface=lo --interface=lxcbr0 --dhcp-leasefile=/var/lib/misc/dnsmasq.lxcbr0.leases --dhcp-authoritative
root 27502 0.0 0.1 15944 2124 pts/17 S+ 07:44 0:00 grep --color=auto dnsmasq

使用異動後的虛擬網路架構
雖然可以利用指令讓 LXC 虛擬主機連結到新的網路架構上, 但是虛擬主機是不是真的能夠在異動後的網路架構中運作? 這裡使用 myUS14 虛擬主機作為示範:
# lxc-start -n myUS14 -d // 啟動虛擬主機 
# lxc-console -n myUS14 // 連接虛擬主機

Connected to tty 1
Type to exit the console, to enter Ctrl+a itself
...
myUS14 login:
 ubuntu
Password: ubuntu
Last login: Sun Aug 23 03:29:03 PDT 2015 on lxc/tty1
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.19.0-25-generic x86_64)

* Documentation: https://help.ubuntu.com/

ubuntu@myUS14:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:16:3e:65:9b:85
inet addr:10.0.100.239 Bcast:10.0.100.255 Mask:255.255.255.0

由上面輸出可以知道變更後的網路架構生效, 接著我們要建立新的虛擬主機 "ubuntu14" 來確認其網路架構:
# lxc-create -t ubuntu -n ubuntu14
Checking cache download in /var/cache/lxc/trusty/rootfs-amd64 ...
Copy /var/cache/lxc/trusty/rootfs-amd64 to /var/lib/lxc/ubuntu14/rootfs ...
Copying rootfs to /var/lib/lxc/ubuntu14/rootfs ...
...
##
The default user is 'ubuntu' with password 'ubuntu'!
# Use the 'sudo' command to run tasks as root in the container.
##
...

# lxc-start -n ubuntu14 -d
# lxc-console -n ubuntu14

Connected to tty 1
Type to exit the console, to enter Ctrl+a itself

Ubuntu 14.04.3 LTS ubuntu14 tty1

ubuntu14 login:
 ubuntu
Password:
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.19.0-25-generic x86_64)


$ ip addr show eth0 // 現在在虛擬主機內了, 接著來檢設 eth0 的網路設定
40: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:16:3e:49:de:a3 brd ff:ff:ff:ff:ff:ff
inet 10.0.100.235/24 brd 10.0.100.255 scope global eth0

由上面可以確認派發的 IP 落在設定的範圍 "10.0.100.200~10.0.100.250" 內. 接著來檢視一下網路連線狀況:
$ ping -c 3 www.google.com.tw // 檢視是否可以連到 Internet
PING www.google.com.tw (173.194.72.94) 56(84) bytes of data.
64 bytes from tf-in-f94.1e100.net (173.194.72.94): icmp_seq=1 ttl=127 time=34.2 ms
...

$ ping -c 3 10.0.100.239 // 檢視是否可以連接到虛擬主機 myUS14
PING 10.0.100.239 (10.0.100.239) 56(84) bytes of data.
64 bytes from 10.0.100.239: icmp_seq=1 ttl=64 time=0.084 ms
...


2015年8月25日 星期二

[ 常見問題 ] Limit disk size and bandwidth of a Docker container

Source From Here
Question
I have a physical host machine with Ubuntu 14.04 running on it. It has 100G disk and 100M network bandwidth. I installed Docker and launched 10 containers. I would like to limit each container to a maximum of 10G disk and 10M network bandwidth.

After going though the official documents and searching on the Internet, I still can't find a way to allocate specified size disk and network bandwidth to a container. I think this may not be possible in Docker directly, maybe we need to bypass Docker. Does this means we should use something "underlying", such as LXC or Cgroup? Can anyone give some suggestions?

How-To
I don't think this is possible right now using Docker default settings. Here's what I would try.

About disk usage:
You could tell Docker to use the DeviceMapper storage backend instead of AuFS. This way each container would run on a block device (Devicemapper dm-thin target) limited to 10GB (this is a Docker default, luckily enough it matches your requirement!).

According to this link, it looks like latest versions of Docker now accept advanced storage backend options. Using the devicemapperbackend, you can now change the default container rootfs size option using --storage-opt dm.basesize=20G (that would be applied to any newly created container).

To change the storage backend: use the --storage-driver=devicemapper Docker option. Note that your previous containers won't be seen by Docker anymore after the change.

About network bandwidth
You could tell Docker to use LXC under the hoods : use the -e lxc option. Then, create your containers with a custom LXC directive to put them into a traffic class :
# docker run --lxc-conf="lxc.cgroup.net_cls.classid = 0x00100001" your/image /bin/stuff

Check the official documentation about how to apply bandwidth limits to this class. I've never tried this myself (my setup uses a custom OpenVswitch bridge and VLANs for networking, so bandwidth limitation is different and somewhat easier), but I think you'll have to create and configure a different class.

Note : the --storage-driver=devicemapper and -e lxc options are for the Docker daemon, not for the Docker client you're using when running docker run ...

Supplement
Docker document - Daemon storage-driver option
The Docker daemon has support for several different image layer storage drivers: aufs, devicemapper, btrfs, zfs and overlay...The option dm.basesizespecifies the size to use when creating the base device, which limits the size of images and containers. The default value is 100G. Note, thin devices are inherently “sparse”, so a 100G device which is mostly empty doesn’t use 100 GB of space on the pool. However, the filesystem will use more space for the empty case the larger the device is...


[ VMware 常見問題 ] Command Line Application for Automatic Launching VM

Source From Here 
Preface 
VMware Workstation includes a separate application, vmrun, for operating teams or virtual machines from the command line. To launch the vmrun application, from the command prompt, enter: 
vmrun COMMAND [OPTION]


Usage 
Valid vmrun commands and options are described in the following table: 
 

Note. Before running this command on a Windows host, you must do one of the following: 
* Change your working directory to the VMware Workstation directory. The default location is: c:\Program Files\VMware\VMware Workstation
* Add the VMware Workstation directory to the system path.

Examples for vmrun 
For example, to start a virtual machine: 
- In a Linux terminal, enter 
# vmrun start /usr/local/VMs/<virtual_machine_name>.vmx

- On the Windows command line, enter: 
$ vmrun start c:\My Virtual Machines\<virtual_machine_name>.vmx

With virtual machines that require input through a VMware Workstation dialog box, vmrun may time out and fail. To disable Workstation dialog boxes, insert the following line into the .vmx configuration file for a virtual machine: msg.autoAnswer = TRUE

2015年8月23日 星期日

[ Python 文章收集 ] Dive Into Python - Dynamically importing modules

Source From Here 
Preface 
First, let's look at how you normally import modules. The import module syntax looks in the search path for the named module and imports it by name. You can even import multiple modules at once this way, with a comma-separated list. You did this on the very first line of this chapter's script. 

Example 16.13. Importing multiple modules at once 
  1. import sys, os, re, unittest  
This imports four modules at once: sys (for system functions and access to the command line parameters), os (for operating system functions like directory listings), re (for regular expressions), and unittest (for unit testing). Now let's do the same thing, but with dynamic imports. 

Example 16.14. Importing modules dynamically 
>>> sys = __import__('sys') ...(1)
>>> os = __import__ ('os')
>>> re = __import__('re')
>>> unittest = __import__('unittest')
>>> sys ...(2)

>>> os

(1) The built-in __import__ function accomplishes the same goal as using the import statement, but it's an actual function, and it takes a string as an argument. 
(2) The variable sys is now the sys module, just as if you had said import sys. The variable os is now the os module, and so forth. 

So __import__ imports a module, but takes a string argument to do it. In this case the module you imported was just a hard-coded string, but it could just as easily be a variable, or the result of a function call. And the variable that you assign the module to doesn't need to match the module name, either. You could import a series of modules and assign them to a list. 

Example 16.15. Importing a list of modules dynamically 
>>> moduleNames = ['sys', 'os', 're', 'unittest'] ... (1)
>>> moduleNames
['sys', 'os', 're', 'unittest']
>>> modules = map(__import__, moduleNames) ...(2)
>>> modules ...(3)
[, , , ]
>>> modules[0].version ...(4)
'2.7.5 (default, Jun 24 2015, 00:41:19) \n[GCC 4.8.3 20140911 (Red Hat 4.8.3-9)]'
>>> import sys
>>> sys.version
'2.7.5 (default, Jun 24 2015, 00:41:19) \n[GCC 4.8.3 20140911 (Red Hat 4.8.3-9)]'

(1) moduleNames is just a list of strings. Nothing fancy, except that the strings happen to be names of modules that you could import, if you wanted to. 
(2) Surprise, you wanted to import them, and you did, by mapping the __import__ function onto the list. Remember, this takes each element of the list (moduleNames) and calls the function (__import__) over and over, once with each element of the list, builds a list of the return values, and returns the result. 
(3) So now from a list of strings, you've created a list of actual modules. (Your paths may be different, depending on your operating system, where you installed Python, the phase of the moon, etc.
(4) To drive home the point that these are real modules, let's look at some module attributes. Remember, modules[0] is the sys module, so modules[0].version issys.version. All the other attributes and methods of these modules are also available. There's nothing magic about the import statement, and there's nothing magic about modules. Modules are objects. Everything is an object.

[ Big Data 研究 ] 03 管理 Linux Container 虛擬主機

LXC 虛擬主機的進階使用與設定 
目前 LXC 虛擬主機只提供終端機操作介面, 並未提供圖形操作介面, 這是與其他虛擬系統相比的最大差異. 也就是說 LXC 虛擬主機所有的操控, 都是在終端機文字介面下執行. 為何 LXC 虛擬主機並沒有提供圖形操作介面呢? 要了解原因就需要了解 LXC 核心模組與其他虛擬系統的差異. 

目前大部分主流的虛擬系統, 不管事寄居架構 (Hosted Architecture, 例如 VMware Workstation, Virtual Box) 或是裸機架構 (Bare-Metal, 例如 VMware ESXi, Linux KVM), 在架構上可以明確的區分出實體主機 (Host OS) 與 虛擬主機 (Guest OS) 這兩部分, 且兩者的檔案系統相互獨立. 所有的資料的存取與異動, 都需要透過兩層檔案系統的轉換 (虛擬與實體). 即使是裸機架構, 也無法完全避免. 然而 LXC 核心模組的虛擬主機, 則與實體主機共用相同的檔案系統, 對實體主機而言, LXC 虛擬主機的存在就如同一個資料夾, 且虛擬主機與實體主機之間, 共享所有的系統資源!

LXC 虛擬主機的形成, 是以實體主機支援虛擬化的系統核心為基礎, 再以實體主機內部的硬體為資源, 依照所選用的範本, 堆疊出虛擬主機的架構. 這種虛擬主機形成的方式, 就如同 FloppyFW 這套磁片式防火牆一樣, 只需要提供一個作業系統核心, 再給予運作所需要的指令套件, 就能夠組成可以獨立運作的一套作業系統. 在這樣的條件之下, 就 FloppyFW 的虛擬主機而言, 並不需要所謂的桌面套件, 因為這不只會讓整個系統容量變大, 對於實際運作與效能, 並沒有任何助益. 

FloppyFW 的虛擬主機是利用終端機介面來操作, 在相同的概念下, LXC 虛擬主機在原生的架構下, 當然也只需利用終端機介面來操作. 不過現在問題來了, 當我們使用 "sudo lxc-start -n myUS14" 指令來啟動 myUS14 虛擬主機時, 當下的終端機視窗會直接進入虛擬主機之內. 這樣的設計會占用目前的終端機視窗, 這在某些情況下, 其實還蠻不方便的. 那麼該如何操作, 才能同時兼顧並順利的在實體主機與虛擬主機之間切換呢? 

Console 連線模式 
一般在終端機操作命令或執行程式的時候, 等待回應或結果的時間過長, 則終端機就會處於被占用的狀態. 簡單來說就是此時無法利用此終端機再進行其他的工作, 必須等待程式結束, 不然就只好另外開啟新的終端機視窗來作業, 因此比較有經驗的使用者會利用 "&" 參數將程序丟到背景來執行, 釋放此終端機的操作權, 讓使用者可以繼續執行下一命令. 

就 LXC 核心模組來說, 我們也可以使用以下指令將虛擬主機丟到終端機背景執行: 
// -d: 此參數將指定的虛擬主機於背景執行.
# lxc-start -n myUS14 -d
# ps aux | grep lxc-start
root 16625 0.2 0.1 43160 3496 ? Ss 00:22 0:00 lxc-start -n myUS14 -d

此時 myUS14 虛擬主機已經在背景中執行, 這時終端機的操作權會再實體主機上. 而丟到背景執行的程式是可以利用特定指令將其再拉回終端機前景執行. 而在系統背景執行的 myUS14虛擬主機, 也有 LXC 核心模組提供的連線模式, 讓使用者可以直接連接到背景執行的虛擬主機上的終端機. 這樣的連線模式稱為 "Console 連線模式". 

LXC 核心模組提供的 Console 連線模式, 可以讓我們直接連到系統背景中執行的 LXC 虛擬主機, 直接進行系統的設定與管理. 透過指令 lxc-console 並使用下面命令可以讓你進入背景執行的 myUS14 虛擬主機: 
// -n, --name=NAME NAME for name of the container
// -t, --tty=NUMBER console tty number
// -e, --escape=PREFIX prefix for escape command

# lxc-console -n myUS14
Connected to tty 1
Type to exit the console,  to enter Ctrl+a itself

Ubuntu 14.04.3 LTS myUS14 tty1

myUS14 login:

利用 Console 連線模式進入 LXC 虛擬主機後, 在任何情況下, 不管是否已經登出, 按下 "Ctrl+a" 的組合鍵再按下 "q" 鍵就可以脫離 Console 連線模式回到實體主機的終端視窗. 接著我們可以透過指令 lxc-ps 得知有多少 LXC 虛擬主機運行於背景中: 
 

自訂 Linux 指令 
一個完整的指令 "shutdown -h now", 對熟悉 Linux 的人來說, 或啥沒什麼. 但對一般使用者要記住這些繁雜的指令與參數, 就非常不容易. 為了操作與管理上的方便性, 這時就可以使用 "alias" 來簡化需多常用指令與參數組合. "alias" 又成別名, 簡單來說就是利用 alias 設定一個自訂指令, 來替代並簡化原本一長串參數的指令列. 如果是個別使用者設定, 可以將 alias 設置於 /home/<user>/.bashrc 裡面 ( 為個別使用者名稱); 如果是全域的設定, 則可以設定到 /etc/profile 中. 底下是後面範例會使用的別名設定: 
  1. alias ping='ping -c 4'  
  2. alias bye='sudo shutdown -h now'  
Linux 虛擬主機系統中文化 
安裝的 LXC 虛擬主機預設為英文語系, 若想支援中文顯示, 可以安裝中文語系的套件包, 使用下面指令來安裝: 
# apt-get install language-pack-zh-hant
...
Generating locales...
zh_HK.UTF-8... done
zh_TW.UTF-8... done
Generation complete.

安裝完成之後, 還需要再 /etc/profile 檔案內指定以中文語系為主: 
  1. export LANG=zh_TW.UTF-8  
  2. export LANGUAGE=zh_TW.UTF-8  
設定完畢後, 使用指令 'exit' 登出系統後再重新登入才能使設定生效. 

管理多部 LXC 虛擬主機 (終端機分頁) 
當 LXC 虛擬主機的數量只有少數幾台時, 以 Console 連線模式來管理還算可行, 但是虛擬主機的數量一多起來, 就不太適合這種在單一終端機下的連線模式. 一般的終端機視窗, 一次只能連線到一台虛擬主機, 且也只能看到單一虛擬主機的運作狀況, 想要一次管理多台虛擬主機, 較直覺的方式大概就是連續開啟多個終端機視窗, 並連接到不同的虛擬主機. 但最大的缺點就是這些連續開啟的終端機視窗會將螢幕佔的滿滿的, 非常不方便. 面對這種情況, 若要簡化終端機管理的頁面, 就需要利用到終端機視窗的分頁模式. 

所謂的分頁模式, 就是在單一終端機視窗內, 產生多個頁面, 就像是瀏覽器開啟多個分頁瀏覽網頁一樣. 而這樣的好處就是可以節省桌面被占用的空間, 在管理上也可以比較直覺且不容易搞混. 另外啟動分頁時, 也可以附加執行特定的指令, 只需要撰寫客製化的 "Bash Script", 就可以再啟動分頁時一併執行. 

在實體主機目前的使用者家目錄中, 使用下面指令, 建立名稱為 "srvlxc" 的 Bash Script 程式, 而程式的名稱可依讀者需求自行設定, 接著輸入以下程式內容: 
- srvlxc 
  1. #!/bin/sh  
  2. "$#" != "1" ] && echo "srv.sh lxc-system" && exit 1  
  3.   
  4. p=$(ps aux)  
  5. echo $p | grep "lxc-start .n $1 .d" &>/dev/null  
  6.   
  7. if [ "$?" == "0" ]; then  
  8.     echo -n "Press a to connect; c to close:"  
  9.     read ans  
  10.     if [ "$ans" == "a" ]; then  
  11.         sudo lxc-console -n $1  
  12.     elif [ "$ans" == "c" ]; then  
  13.         sudo lxc-stop -n $1  
  14.     fi  
  15. else  
  16.     echo -n "$1 starting..."  
  17.     sudo lxc-start -n $1 -d &>/dev/null  
  18.     p=$(ps aux)  
  19.     echo $p | grep "lxc-start .n $1 .d" &>/dev/null  
  20.     [ "$?" != "0" ] && echo "Fail!" && exit 1  
  21.     sleep 6  
  22.     echo "Success!"  
  23.     lxc-console -n $1  
  24. fi  
程式輸入完畢後, 使用下面指令賦予此程式執行權限: 
# chmod +x srvlxc

接著來設定終端機分頁, 點選終端機上的 "檔案" -> "新增設定組合", 此時系統會跳出 "新增設定組合" 的視窗, 在 "設定組合名稱" 的欄位上, 填入自訂的的終端機分頁名稱, 而此分頁名稱也是執行 "srvlxc" 程式所需要的輸入參數, 也就是我們要啟動的虛擬主機名稱: 
 

接著點選 "建立", 就會跳出 "正在編輯設定組合 myUS14" 的視窗, 請按照下面步驟完成設定: 
 
(上面的 /home/root/srvlxc 路徑改為你自己的路徑, 並加上 sudo 確保沒有權限問題

設定完成點擊 "關閉/Close" 來關閉設定視窗. 接著回到終端機視窗, 從上方工具列點選 "檔案" -> "開啟分頁" 並點選 "myUS14" 選項: 
 

執行後可以發現新的分頁 "myUS14" 如下: 
 

批次啟動及關閉終端機分頁 
若每次都需要啟動多台虛擬主機, 則可以使用下面指令建立批次啟動終端機分頁的程式 "startMultiCant" 
# vi startMultiCant
  1. #!/bin/sh  
  2. gnome-terminal --geometry 90x45 --tab-with-profile=myUS14 --tab-with-profile=myCentOS  

接著可以使用 "chmod +x startMultiCant" 讓該 Bash Script 具備執行權限, 並執行該 Bash Script 確認 "myUS14" 與 "myCentOS" 虛擬主機有同時在不同分頁被啟動: 
$ lxc-ls // 檢視現有啟動的虛擬主機
$ ./startMultiCant // 同時啟動虛擬主機 "myUS14" 與 "myCentOS"



Supplement 
04 管理 Linux Container 虛擬網路 - Part1
04 管理 Linux Container 虛擬網路 - Part2

[Git 常見問題] error: The following untracked working tree files would be overwritten by merge

  Source From  Here 方案1: // x -----删除忽略文件已经对 git 来说不识别的文件 // d -----删除未被添加到 git 的路径中的文件 // f -----强制运行 #   git clean -d -fx 方案2: 今天在服务器上  gi...