HVCS IBM “Hypervisor Virtual Console Server” 安裝指南

適用於 Linux Kernel 2.6.4+

版權 (C) 2004 IBM Corporation

作者: Ryan S. Arnold <rsa@us.ibm.com>

建立日期: 2004 年 3 月 2 日 最後修改: 2004 年 8 月 24 日

1. 驅動程式介紹:

這是 IBM Hypervisor Virtual Console Server, “hvcs” 的裝置驅動程式。 IBM hvcs 提供了一個 tty 驅動程式介面,允許 Linux 使用者空間應用程式訪問執行在同一分割槽 Power5 ppc64 系統上的邏輯分割槽作業系統 (Linux 和 AIX) 的系統控制檯。 在此硬體上,每個分割槽的物理硬體控制檯並不實用,因此係統控制檯透過此驅動程式使用韌體介面訪問虛擬終端裝置。

2. 系統要求:

此裝置驅動程式使用 2.6.4 Linux 核心 API 編寫,只能在此版本或更高版本的核心上構建和執行。

雖然對從驅動程式程式碼中抽象出架構相關的韌體呼叫採取了一些措施,但該驅動程式的編寫目的是僅在 IBM Power5 ppc64 硬體上執行。

Sysfs 必須掛載在系統上,以便使用者可以確定哪些主裝置號和次裝置號與每個 vty-server 相關聯。 sysfs 掛載的說明不在本文件的範圍之內。

3. 構建選項:

hvcs 驅動程式將自身註冊為 tty 驅動程式。 tty 層動態分配一個由註冊驅動程式請求數量的主裝置號和次裝置號塊。 預設情況下,hvcs 驅動程式請求 tty 層分配 64 個主裝置號/次裝置號以用於 hvcs 裝置節點條目。

如果預設的裝置條目數量足夠,則可以將此驅動程式構建到核心中。 如果不夠,則可以使用 insmod 引數將驅動程式作為模組插入來覆蓋預設值。

3.1 內建:

以下 menuconfig 示例演示了選擇將此驅動程式構建到核心中

Device Drivers  --->
        Character devices  --->
                <*> IBM Hypervisor Virtual Console Server Support

開始核心 make 過程。

3.2 模組:

以下 menuconfig 示例演示了選擇將此驅動程式構建為核心模組

Device Drivers  --->
        Character devices  --->
                <M> IBM Hypervisor Virtual Console Server Support

make 過程將構建以下核心模組

  • hvcs.ko

  • hvcserver.ko

要使用預設分配插入模組,請按出現的順序執行以下命令

insmod hvcserver.ko
insmod hvcs.ko

hvcserver 模組包含架構特定的韌體呼叫,必須首先插入,否則 hvcs 模組將無法找到它期望的一些符號。

要覆蓋預設值,請使用如下所示的 insmod 引數 (以請求 4 個 tty 裝置為例)

insmod hvcs.ko hvcs_parm_num_devs=4

可以在 insmod 上指定的最大 dev 條目數。 我們認為目前允許的最大伺服器介面卡數量為 1024 個。 可以透過在構建之前修改原始檔中的常量來隨時更改此數量。

注意: 插入驅動程式所需的時間長度似乎與註冊驅動程式請求的 tty 介面數量有關。

為了刪除驅動程式模組,請執行以下命令

rmmod hvcs.ko

將 hvcs 作為模組安裝的推薦方法是使用 depmod 在 /lib/modules/uname -r 中構建一個當前的 modules.dep 檔案,然後執行

modprobe hvcs hvcs_parm_num_devs=4

modules.dep 檔案指示 hvcserver.ko 需要在 hvcs.ko 之前插入,modprobe 使用此檔案智慧地按正確的順序插入模組。

以下 modprobe 命令用於按正確的順序刪除 hvcs 和 hvcserver

modprobe -r hvcs

4. 安裝:

tty 層建立 sysfs 條目,其中包含為 hvcs 驅動程式分配的主裝置號和次裝置號。 以下“tree”命令輸出的 sysfs 目錄片段顯示了這些數字的顯示位置

sys/
|-- *other sysfs base dirs*
|
|-- class
|   |-- *other classes of devices*
|   |
|   `-- tty
|       |-- *other tty devices*
|       |
|       |-- hvcs0
|       |   `-- dev
|       |-- hvcs1
|       |   `-- dev
|       |-- hvcs2
|       |   `-- dev
|       |-- hvcs3
|       |   `-- dev
|       |
|       |-- *other tty devices*
|
|-- *other sysfs base dirs*

對於上面的示例,以下輸出是 cat'ing hvcs 目錄中的“dev”條目的結果

Pow5:/sys/class/tty/hvcs0/ # cat dev
254:0

Pow5:/sys/class/tty/hvcs1/ # cat dev
254:1

Pow5:/sys/class/tty/hvcs2/ # cat dev
254:2

Pow5:/sys/class/tty/hvcs3/ # cat dev
254:3

從讀取“dev”屬性的輸出是 tty 層為此驅動程式使用分配的字元裝置主裝置號和次裝置號。 大多數執行 hvcs 的系統都已經建立了裝置條目,或者 udev 會自動執行此操作。

鑑於上面的示例輸出,要手動建立 /dev/hvcs* 節點條目,可以使用 mknod,如下所示

mknod /dev/hvcs0 c 254 0
mknod /dev/hvcs1 c 254 1
mknod /dev/hvcs2 c 254 2
mknod /dev/hvcs3 c 254 3

使用 mknod 手動建立裝置條目使這些裝置節點持久存在。 建立後,它們將在驅動程式 insmod 之前存在。

在插入 hvcs 模組之前嘗試將應用程式連線到 /dev/hvcs* 將導致類似於以下的錯誤訊息

"/dev/hvcs*: No such device".

注意: 僅僅因為存在裝置節點並不意味著為該節點配置了 vty-server 裝置。

5. 連線

由於此驅動程式控制提供 tty 介面的裝置,因此使用者可以使用任何標準的 tty 互動方法(例如“cat”、“dd”、“echo”)與裝置節點條目進行互動。 然而,此驅動程式的目的是提供與 Linux 分割槽控制檯的即時控制檯互動,這需要使用提供與 tty 裝置的雙向互動式 I/O 的應用程式。

充當終端模擬器或對透過它們的資料執行終端型別控制序列轉換的應用程式(例如“minicom”和“screen”)對於提供互動式控制檯 I/O 是不可接受的。 這些程式通常模擬過時的終端型別(vt100 和 ANSI),並期望入站資料採用這些受支援的終端型別之一的形式,但它們要麼不轉換,要麼沒有_充分_地將出站資料轉換為呼叫它們的終端的終端型別 (儘管 screen 進行了嘗試,並且顯然可以透過大量的 termcap 操作進行配置)。

因此,kermit 和 cu 是透過 hvcs 裝置與 Linux 控制檯互動的兩種推薦應用程式。 這些程式只是充當來往於 tty 裝置的資料傳輸的管道。 它們不要求入站資料採用特定終端型別的形式,也不將出站資料烹飪成特定終端型別。

為了確保控制檯應用程式的正常執行,必須確保一旦連線到 /dev/hvcs 控制檯,控制檯的 $TERM 環境變數設定為用於啟動互動式 I/O 應用程式的終端模擬器的確切終端型別。 如果有人使用 xterm 和 kermit 連線到 /dev/hvcs0,當控制檯提示符可用時,應該在控制檯上“export TERM=xterm”。 這告訴從控制檯呼叫的 ncurses 應用程式,它們應該輸出 xterm 可以理解的控制序列。

作為預防措施,hvcs 使用者應始終在從裝置節點斷開諸如 kermit 之類的應用程式之前“exit”退出會話。 如果不這樣做,下一個連線到控制檯的使用者將繼續使用前一個使用者登入的會話,包括使用前一個使用者提供的 $TERM 變數。

vty-server 介面卡的熱插拔新增和刪除會影響哪個 /dev/hvcs* 節點用於連線到每個 vty-server 介面卡。 為了確定哪個 vty-server 介面卡與哪個 /dev/hvcs* 節點相關聯,已將一個特殊的 sysfs 屬性新增到每個 vty-server sysfs 條目。 此條目稱為“index”,顯示它會顯示一個整數,該整數引用用於連線到該裝置的 /dev/hvcs* 條目。 例如,cat vty-server 介面卡 30000004 的索引屬性顯示如下

Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat index
2

此索引“2”意味著為了連線到 vty-server 介面卡 30000004,使用者應與 /dev/hvcs2 進行互動。

應該注意的是,由於系統的熱插拔 I/O 功能,與特定 vty-server 介面卡互動的 /dev/hvcs* 條目不能保證在系統重啟後保持不變。 有關此問題的更多資訊,請參見問答部分。

6. 斷開連線

作為一項安全功能,為了防止將過時的資料傳遞給非預期目標,Power5 系統韌體會在 vty-server 和 vty 之間的連線斷開時停用資料的獲取並丟棄該資料。 例如,當 vty-server 在將資料輸出到 vty 後立即從 vty 斷開連線時,vty 介面卡可能沒有足夠的時間在收到資料中斷和連線斷開之間從韌體獲取資料,然後韌體停用該獲取。

當 hvcs 用於服務控制檯時,此行為不是一個大問題,因為介面卡在幾乎所有資料寫入後都會保持連線很長時間。 當 hvcs 用作 tty 管道在兩個分割槽之間隧道傳輸資料時 [請參見下面的問答] 這是一個巨大的問題,因為當 cat'ing 或 dd'ing 資料到裝置時,標準的 Linux 行為是開啟 tty,傳送資料,然後關閉 tty。 如果此驅動程式在 tty 關閉時手動終止 vty-server 連線,則這會在目標 vty 有機會獲取資料之前關閉 vty-server 和 vty 連線。

此外,僅在模組刪除或介面卡刪除時斷開 vty-server 和 vty 的連線是不切實際的,因為其他分割槽中的其他 vty-server 可能隨時需要使用目標 vty。

由於此行為限制,從連線的 vty 斷開 vty-server 是一個手動過程,需要寫入下面概述的 sysfs 屬性,另一方面,此驅動程式會自動建立到 vty 的初始 vty-server 連線。 永遠不需要手動 vty-server 連線。

為了終止 vty-server 和 vty 之間的連線,使用了每個 vty-server 的 sysfs 條目中的“vterm_state”sysfs 屬性。 讀取此屬性會顯示 vty-server 介面卡的當前連線狀態。 零表示 vty-server 未連線到 vty。 一表示連線處於活動狀態。

將“0”(零)寫入 vterm_state 屬性將僅在 vterm_state 之前讀取為“1”時斷開 vty-server 和目標 vty 之間的 VTERM 連線。 如果 vterm_state 讀取為“0”,或者如果將“0”以外的任何值寫入 vterm_state 屬性,則會忽略寫入指令。 以下示例將顯示用於驗證 vty-server 連線狀態和斷開 vty-server 連線的方法

Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat vterm_state
1

Pow5:/sys/bus/vio/drivers/hvcs/30000004 # echo 0 > vterm_state

Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat vterm_state
0

當熱插拔刪除裝置和刪除模組時,所有 vty-server 連線都會自動終止。

7. 配置

每個 vty-server 在 /sys/devices/vio 目錄中都有一個 sysfs 條目,該條目在幾個其他 sysfs 樹目錄中進行了符號連結,尤其是在 hvcs 驅動程式條目下,如下面的示例所示

Pow5:/sys/bus/vio/drivers/hvcs # ls
.  ..  30000003  30000004  rescan

按照設計,韌體通知 hvcs 驅動程式 vty-server 的生存期和夥伴 vty 的刪除,但不通知夥伴 vty 的新增。 由於 HMC 超級管理員可以動態新增夥伴資訊,因此我們為 hvcs 驅動程式 sysfs 目錄提供了“rescan”更新屬性,該屬性將查詢韌體並更新此驅動程式管理的所有 vty-server 的夥伴資訊。 將“1”寫入屬性會觸發更新。 下面是一個明確的示例

Pow5:/sys/bus/vio/drivers/hvcs # echo 1 > rescan

讀取該屬性將指示狀態“1”或“0”。 一表示更新正在進行中。 零表示更新已完成或從未執行。

此目錄中的 Vty-server 條目是由韌體建立的 32 位分割槽唯一單元地址。 一個 vty-server sysfs 條目的示例如下所示

Pow5:/sys/bus/vio/drivers/hvcs/30000004 # ls
.   current_vty   devspec       name          partner_vtys
..  index         partner_clcs  vterm_state

預設情況下,每個條目都提供一個“name”屬性。 讀取“name”屬性將顯示裝置型別,如以下示例所示

Pow5:/sys/bus/vio/drivers/hvcs/30000003 # cat name
vty-server

預設情況下,每個條目還提供一個“devspec”屬性,該屬性在讀取時顯示完整的裝置規範,如以下示例所示

Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat devspec
/vdevice/vty-server@30000004

每個 vty-server sysfs dir 都提供兩個只讀屬性,這些屬性提供易於解析的夥伴 vty 資料列表:“partner_vtys”和“partner_clcs”

Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat partner_vtys
30000000
30000001
30000002
30000000
30000000

Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat partner_clcs
U5112.428.103048A-V3-C0
U5112.428.103048A-V3-C2
U5112.428.103048A-V3-C3
U5112.428.103048A-V4-C0
U5112.428.103048A-V5-C0

讀取 partner_vtys 會返回一個夥伴 vty 列表。 Vty 單元地址編號僅是每個分割槽唯一的,因此條目會經常重複。

讀取 partner_clcs 會返回一個“融合位置程式碼”列表,該列表由系統序列號後跟“-V*”組成,其中“*”是目標分割槽號,以及“-C*”,其中“*”是介面卡的插槽。 第一個 vty 夥伴對應於第一個 clc 項,第二個 vty 夥伴對應於第二個 clc 項,依此類推。

一個 vty-server 一次只能連線到一個 vty。 讀取條目“current_vty”時,會列印當前選定的夥伴 vty 的 clc。

可以透過將有效的夥伴 clc 寫入條目來更改 current_vty,如以下示例所示

Pow5:/sys/bus/vio/drivers/hvcs/30000004 # echo U5112.428.10304
8A-V4-C0 > current_vty

當 vty-server 已經連線到 vty 時更改 current_vty 不會影響當前連線。 當釋放當前開啟的連線時,更改才會生效。

有關“vterm_state”屬性的資訊已在前面標題為“斷開連線”的章節中介紹。

8. 問題與解答:

問: 涉及 hvcs 的安全問題有哪些?

答: 主要有三個安全問題

1. /dev/hvcs* 節點的建立者能夠限制裝置條目對某些使用者或組的訪問。 最好建立一個特殊的 hvcs 組許可權,以提供對系統控制檯的訪問許可權。

2. 為了在獲取控制檯時提供網路安全性,建議使用者使用安全方法(例如 SSH)連線到託管分割槽的控制檯,或者坐在硬體控制檯上。

3. 確保在使用控制檯後退出使用者會話,否則下一個 vty-server 連線(可能來自另一個分割槽)將體驗到先前登入的會話。


問: 如何多路複用我透過 hvcs 獲取的控制檯,以便其他人可以看到它

答: 您可以使用“screen”直接連線到 /dev/hvcs* 裝置,並在您的機器上使用控制檯組許可權設定會話。 如前所述,預設情況下,screen 不提供大多數終端模擬器的 termcap 設定,以提供從 term 型別“screen”到其他型別的充分字元轉換。 這意味著基於 curses 的程式可能無法在 screen 會話中正確顯示。


問: 為什麼顏色都搞砸了? 問: 為什麼控制字元的行為很奇怪或不起作用? 問: 為什麼控制檯輸出都很奇怪且難以理解?

答: 請參閱前面的“連線”部分,以瞭解應用程式如何影響字元控制序列的顯示。 此外,僅僅因為您使用 xterm 登入到控制檯並不意味著其他人沒有在您之前使用 HMC 控制檯 (vt320) 登入到控制檯並離開登入的會話。 最好的方法是在您獲得控制檯時將 TERM 匯出到您的終端模擬器的終端型別。 此外,請確保在斷開與控制檯的連線之前“exit”退出控制檯。 這將確保下一個使用者在登入時獲得他們自己的 TERM 型別設定。


問: 當我嘗試將 kermit 連線到 hvcs 裝置時,我得到:“Sorry, can't open connection: /dev/hvcs*”發生了什麼事?

答: 某些其他 Power5 控制檯機制已連線到 vty,並且不放棄它。 您可以嘗試透過右鍵單擊分割槽然後選擇“關閉終端”來強制從 HMC 斷開控制檯。 否則,您必須找出擁有控制檯許可權的人員。 您可能已經使用另一個 kermit 會話打開了控制檯,只是忘記了它。 請檢視 Power5 系統的控制檯選項,以確定可以保持系統控制檯的多種方式。

或者

答: 另一個使用者可能當前沒有連線到 /dev/hvcs 裝置的連線方法,但 vterm_state 可能會顯示他們仍然建立了 vty-server 連線。 他們需要使用“斷開連線”部分中概述的方法來釋放此連線,以便其他人可以連線到目標 vty。

或者

答: 您用於執行 kermit 的使用者配置檔案可能沒有使用 /dev/hvcs* 裝置的許可權。

或者

答: 您可能尚未插入 hvcs.ko 模組,但 /dev/hvcs* 條目仍然存在(在沒有 udev 的系統上)。

或者

答: 沒有對映到現有 /dev/hvcs* 條目的相應 vty-server 裝置。


問: 當我嘗試將 kermit 連線到 hvcs 裝置時,我得到:“Sorry, write access to UUCP lockfile directory denied.”

答: 您指定的 /dev/hvcs* 條目不存在於您所說的位置? 也許您尚未插入模組(在具有 udev 的系統上)。


問: 如果我已經安裝了一個 Linux 分割槽,我可以使用該分割槽上的 hvcs 來為第二個 Linux 分割槽的安裝提供控制檯嗎?

答: 是的,前提是您使用 kermit 或 cu 或某些不提供終端模擬的其他程式連線到 /dev/hvcs* 裝置。


問: 我可以使用此驅動程式一次連線到多個分割槽的控制檯嗎?

答: 是的。 當然,這意味著必須為此分割槽配置多個 vty-server,並且每個 vty-server 必須指向一個斷開連線的 vty。


問: hvcs 驅動程式是否支援裝置的動態(熱插拔)新增?

答: 是的,如果您的系統啟用了 dlpar 和熱插拔,並且已將其構建到核心中,則 hvcs 驅動程式配置為動態處理新裝置的新增和未使用裝置的刪除。


問: 由於某種原因,/dev/hvcs* 在重新啟動後沒有對映到相同的 vty-server 介面卡。 發生了什麼事?

答: 始終按照暴露介面卡的順序完成將 vty-server 介面卡分配給 /dev/hvcs* 條目。 由於此驅動程式的熱插拔功能,熱插拔新增的 vty-server 的分配順序可能與它們在模組載入時暴露的順序不同。 在動態新增後重新啟動或重新載入模組可能會導致 /dev/hvcs* 和 vty-server 耦合發生變化,如果在兩個其他 vty-server 介面卡之間的插槽中添加了 vty-server 介面卡。 請參閱上面的章節,瞭解如何確定哪個 vty-server 與哪個 /dev/hvcs* 節點一起使用。 提示;檢視 vty-server 的 sysfs“index”屬性。


問: 我可以使用 /dev/hvcs* 作為通向另一個分割槽的管道,並使用該分割槽上的 tty 裝置作為管道的另一端嗎?

答: 是的,在 Power5 平臺上,hvc_console 驅動程式為額外的 /dev/hvc* 裝置提供了一個 tty 介面(其中 /dev/hvc0 最有可能是控制檯)。 為了使兩個分割槽之間的 tty 管道正常工作,HMC 超級管理員必須使用 HMC gui 為目標分割槽建立一個額外的“序列伺服器”,該伺服器在目標分割槽重新啟動時將顯示為 /dev/hvc*。

然後,HMC 超級管理員為當前分割槽建立一個額外的“序列客戶端”,並將該客戶端指向目標分割槽新建立的“序列伺服器”介面卡(記住插槽)。 這顯示為額外的 /dev/hvcs* 裝置。

現在,可以將目標系統上的程式配置為讀取或寫入 /dev/hvc*,並且可以將當前分割槽上的另一個程式配置為讀取或寫入 /dev/hvcs*。 現在,您有兩個分割槽之間的 tty 管道。


9. 報告錯誤:

報告錯誤的正確渠道是透過提供您的作業系統的 Linux OS 發行公司,或者透過將問題釋出到 PowerPC 開發郵件列表中,網址為

linuxppc-dev@lists.ozlabs.org

此請求旨在提供關於此驅動程式的問題和解決方案的記錄和可搜尋的公開交流,以造福所有使用者。