オンプレの必要性
※完全にひとりごとですので。
パブリック・クラウドという素晴らしいプラットフォームが提供されているこのご時世、オンプレ(プライベート・クラウド)環境の必要性を毎日考え続ける日々です。
◯オンプレが必要な環境
どっかの発表でも言ってましたが、オンプレ環境で出来たシステムはオンプレ環境でしか生きないかなと私も思います。まぁ完全に主観ですが。。。
あくまでも憶測ですけどオンプレ環境で出来たシステムって内部APIなるものを使いまくっていて依存性有り有りなシステムかなと思うわけです。なのでパブリックに持って行くとなるとDirectなんちゃらとなるものをやるかー、けどレイテンシーとかどうだっけ？的な色々面倒くさい事考えなくちゃならないかと。また、実際にやるにしてもそれを引くコストといったら・・・(´；ω；｀)
だから面倒くさい事いっそ忘れてオンプレ環境は死に尽き果てるまでオンプレ環境で居座っていた方が得策かなと思うわけです。
あとセキュリティ系が高いものはオンプレ環境だ！とか言うのも個人的にはナンセンスかと。最近パブリック上でも動くセキュリティ製品試したことないけど、それ使えばいいじゃね？って思います。まぁ保証はしないですけど。
だからね、何が言いたいかというとね。
オンプレ環境は過渡期だよ。オンプレはコストが安いとか都市伝説だから！だからちゃんと計画立てろよ！って声を大にして言いたい。
話のまとまりがなくてごめんなさい。
エンジニアな事していません。
愚痴というか今の私の状況について誰に当てるわけでもなく綴りたいと思います。
社内の中で色々変化がおこりまして、
その中で私の立場というか見なきゃならない範囲がエンジニアではなく、組織マネジメントの方に注力しなくてはならなくなりました。
コスト、コスト、コスト、コスト、、、
ワークしてる？ワークしてる？ワークしてる？ワークしてる？
調整、調整、調整、調整、調整、、、
マネジメントしたいと思っていましたが、いざ数ヶ月マネジメントをする立場になるとエンジニア（現場）が凄く恋しいこの頃。
新しいチャレンジだと思って頑張ろうとは思うがどうモチベーションを高くもったままやればいいのか悩みどころです。
( ´ー｀)ﾌｩｰ．．．
KVMのクローンで「Device eth0 does not seem to be present, delaying initialization」と出たら。
お久しぶりです。
最近はもっぱら検証環境の構築で忙しいです。
さて、KVM環境を構築していて改めてKVMの素晴らしさを感じている今日このごろ。
KVM上でクローンを実施した際に出会った問題について書きたいと思います。
■エラーメッセージ
Device eth0 does not seem to be present, delaying initialization
■ゲストOS
・CentOS 6.5
■対応方法
1.MACアドレスの確認
ifconfig だけだとloopbackしか表示されないので、-aをつけましょう。 [root@noge ~]# ifconfig -a eth1 Link encap:Ethernet HWaddr 52:54:00:97:b0:b7 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:10 Base address:0x2000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
上記コマンドで出てきたeth1のMACアドレスをコピーしておく
2.ethの情報書き換え
[root@noge ~]# vim /etc/udev/rules.d/70-persistent-net.rules # PCI device 0x1af4:0x1000 (virtio-pci) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:a1:a8:1d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" # PCI device 0x10ec:0x8139 (8139cp) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:97:b0:b7", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" となっているので eth0の行を削除して、eth1の行を赤文字に書き換える
# PCI device 0x10ec:0x8139 (8139cp) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:97:b0:b7", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
3.ifcfg-eth0のHWADDRを変更
[root@noge ~]# vim /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 IPADDR=192.168.1.101 NETMASK=255.255.255.0 BROADCAST=192.168.1.255 NETWORK=192.168.1.0 GATEWAY=192.168.1.1 NM_CONTROLLED=yes ONBOOT=yes
＃追記or変更 HWADDR=52:54:00:97:B0:B7
ゲストサーバの再起動できっと認識してくれるはず！笑
■参考にさせて頂いたサイト
Netconfをいじってみる その1
検索の神様に「Netconfってどう活用したらいいの？」
って聞いてもいい返事がかえって来ない。
なら、うちの会社の環境で使っている機器でいろいろ検証して見ることにしよう。
ホントうちの会社は自由で良いのか悪いのか(笑)
さて本題・・・。
まず機器側に対して設定を入れてあげなくちゃならない。
今回はこいつを参考に"NETCONF over SSHv2"を使って検証してみた。
1.SSHの設定
## First STEP ## R1> enable R1# configure terminal R1(config) hostname cisco password cisco R1(config) ip domain-name cisco.com R1(config) crypto key generate rsa R1(config) ip ssh timeout 120 R1(config) ip ssh version 2
2.NETCONFの有効化
## Second STEP ## R1> enable R1# configure terminal R1(config) access-list 1 any any R1(config) netconf ssh acl 1 R1(config) netconf lock-time 60 R1(config) netconf max-sessions 5
一応これでひと通りの設定は完了。
意外とさらっと出来るもんだ。
実際にサーバからNETCONFを使って値を取得するのは次回に・・・。
