リモートデスクトップをした際に接続元のタスクバーが 接続先タスクバーの上に表示されてしまうことがたまにある。 原因分からないが、鬱陶しい。 解決策は、接続元で「エクスプローラー」プロセスの再起動を行うことで解消する。 解消手順 タスクマネージャー起動 プロセスタブ→「エクスプローラー」プロセスを右クリック→再起動 このような細かいことは気にしない人が多い。 自分はフルスクリーンじゃないとだめな派です。
VMwareがBroadcomに買収され、人がバサバサ切られ、次は製品に大鉈が振られ、無償版のESXiも当たり前ながら終了となりました。 blogs.vmware.com 無償のESXiと言えば4.0か4.1くらいの頃に無償版が登場して、かれこれ15年くらい提供されてきたので、ちょっとしたサーバーインフラ好きなご家庭なら1つくらいESXi環境があったのではないでしょうか(ほんまか?) うちの自宅も2013年の自作PC導入時のタイミングから10年ちょっと無償版ESXiのお世話になってきました。本当に、今までお世話になりました。 akkiesoft.hatenablog.jp 今後はvSphereのEssentials PlusとStandardが残りつつ、買い切りモデルからサブスクリプションモデルに移行するようですが、自宅サーバーをほそぼそやるには過剰なものになると思うので、別の環境への移行
仮想スイッチは、ESXi 内部で動作する仮想スイッチ(L2)です。仮想スイッチを介して物理アダプタと仮想マシンのネットワークアダプタが接続されます。 仮想スイッチの設定では、仮想スイッチに紐づける物理アダプタの指定などを行います。 ポートグループは仮想アダプタ(仮想マシンのネットワークアダプタ等)が所属するグループです。 ポートグループの設定では、作成先仮想スイッチの指定や Vlan ID の指定(タグ Vlan を使用したい場合)などを行います。 ポートグループに所属する仮想アダプタがどれになるのかについては、仮想アダプタ側の設定で決まります。 例えば仮想マシン作成時のネットワークアダプタ設定ではアダプタの作成先となるポートグループを指定します。 仮想マシン作成画面におけるネットワークアダプタ設定 仮想アダプタは必ずいずれかのポートグループに所属することになります。 VMkernel N
新しい人生のために過去を捨て去ります。 これまでご覧いただきありがとうございました。 メンバーの方はOFUSEまたはメンバー用ブログをご確認ください。
1. 細々とした予備知識 1.1 Qemuのデバイスエミュレーション 1.2 QemuのCPUエミュレーション 1.3 Qemuのスレッド 2. 追加のI/OスレッドとAioContext 2.1 追加のI/Oスレッド 2.2 AioContext 2.3 Big Qemu Lock 3. AioContextの各種イベント処理 3.1 AioHandler 3.2 event_notifier 3.3 タイマー、Bottom half 3.5 スレッドプール 執筆者 : 箕浦 真 こういう 仕事をしていると、ときどきQemuの仕組みや内部動作をお客様に説明する必要があることがあるが、そういう時に「Qemuの〜についてはここを見てね」と言えるような文書があるといいなぁと思って自分で作ってみることにした。 1. 細々とした予備知識 1.1 Qemuのデバイスエミュレーション Qemuはコンピ
今回は、ファイルを仮想ディスク(ブロックデバイス)化し、LVMの作成、拡張、削除などを行う。 OS : Ubuntu16.04 ■準備 $ sudo -i # mkdir /tmp/lvm_test # cd /tmp/lvm_test ■仮想ディスクの作成 ブロックデバイスにするファイルを作成する。 # dd if=/dev/zero of=disk.img bs=1M count=1200 作成したdisk.imgを空いているループバックデバイスに割り当てる # losetup -f disk.img 確認 ★disk.imgにループバックデバイスが割り当てられているか確認 # losetup -l NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE /dev/loop0 0 0 0 0 /tmp/lvm_test/disk.img ディスクラベル
環境 OS:CentOS Linux release 8.3.2011 作業内容 OpenStackのPackstackによる自動構築について検証する。PackstackではCinderによる外部ストレージを設定するが、本環境ではサーバー1台のオールインワン構成で検証しているため外部ストレージは存在しない。 そこで、Linuxのループバックデバイスを使ってボリュームを作成し検証を行う。 本記事ではCentOS 8.3におけるループバックデバイスの作成およびLVMボリュームの作成方法を記載する。 ループバックデバイスとは ファイルをファイルシステムのようにマウントできる機能のことである。 手順 現在のループバックデバイスの状況を確認する。
1台のPCで複数のOSを使い分けるソリューションとして、KVM や VMWare, VirtualBoxのような仮想マシンは今や常識となっています。 しかし、Linuxの上で別のLinux環境を実現するのであればchrootを使っても簡易仮想マシンの様な環境を作ることができます。 Vine Linuxでは、vbootstrap (Vine Linux の基本システムを作成するためのスクリプト)や debootstrap (Debian GNU/Linux bootstrapper)、rinse (Fedora や CentOS 等の chroot 環境を構築するツール)などの便利なパッケージが用意されており、容易に他ディストリビューションをVine Linuxの上で飼うことができます。 ですがここでは、既存のOSがインストール済みのディスクをそのまま活かして、Vine Linux 5.2の
概要 Chromium OSは、ChromebookにインストールされているChrome OSのオープンソース版です。 Chromium OSをVMware PlayerやESXiにインストールし、動かしてみました。 準備 VMware Player、または、ESXi Googleアカウント 手順 Chromium OSをダウンロード Neverware社からCloudReadyをダウンロードします。 CLOUDREADY EDITIONSメニューからHOMEをクリックします。 Where can I find VM images?とあるので、Download VM images →リンクをクリックします。 Download CloudReady Image For VMwareというブログのページが開くので、Download v83 (64bit) CloudReady: Home Ed
以下の環境で確かめました。 前提条件・環境: 古いVMware ESXの環境 VMware ESXi 3.5 仮想マシンはWindows server 2003 SP1 仮想マシンバージョンは4 VMwareスナップショットを古いWMware 3.5上で取得 VMware Tools 3.5 新しいVMware ESXiの環境 VMware vSphere ESXi 5.5 U1 古いVMware ESXのVMFSから仮想マシンデータをフォルダごとコピーし、新しいVMware ESXiのVMFS上にアップロードしました。 結論としてはコピー先でもVMwareスナップショットは認識し戻すことが出来ます 結論としては、コピー先の新しいVMware ESXi上でも旧スナップショットは認識し、スナップショットに戻ることが出来ます。 ちゃんとした作りですね!VMwareスナップショット。 もちろん、
■はじめに vSphere ClientのOVFエクスポート/デプロイを使って、OSクローンを作成します。 ちなみに、同じ手順でOS移行が実施可能です(作業後にクローン元OSを削除)。 だいたい15分ぐらいで出来ました(検証用の単純環境ということもありますが)。 以下記事にて別方式で実施しています。 VMware ESXi 6.0でvSphere ClientからOSクローン作成する(データストアブラウザでコピペ編) https://qiita.com/Higemal/items/0e994973e90dada62768 ■作業イメージ ESXiに存在するOSから、別のデータストアに対してクローンOSを作成します。 ■マシン クローン元OS:Cent 6.4 ホスト名 cent64-gn01 CPU 1core / Memory 2GB / Disk 20GB クローン先OS:Cent 6
来週から開催されるVMworld 2017に先立ってvCenter関連のニュースが発表されました。 まず、FlashベースのWeb Clientが無くなります。 Goodbye, vSphere Web Client 上記の公式ブログによると次期バージョンのvSphereではFlashベースのWeb Clientが”非推奨”となり、サポートする最後のバージョンになるということです。ということはHTML5 Clientがいよいよ主役になります。 HTML5 Clientは現在の最新バージョン(vSphere 6.5 Update 1)でFlashベースのWeb Clientの約90%の機能をカバーしていると言われていますが、次期バージョンのvSphereでは完全にFlashベースのWeb Clientの代わりとして利用できると思いますね。 もう一つのニュースは、Windows版vCenter
「押さえておきたいvSphere の基本」の可用性編の1回目として、前回、vSphere DRSをご紹介しました。 今回は、2回目として、ホスト障害の際にも仮想マシンの稼働を最大化する機能、vShpere HA、vSphere FTに関して順にご紹介します。 ESXiホスト上で稼働している仮想マシンは、そのホストが障害で止まってしまった場合、稼働停止を余儀なくされます。 vSphere HAは、ホスト障害により止まってしまった仮想マシンを他の正常なホスト上で再稼働する機能を提供します。 例えば3台のホストがvSphere HAで構成されている上記の様なケースで、真ん中のホストが何らかの障害により止まってしまった場合、このホスト上で動いていた仮想マシンは停止してしまいます。この障害を検知すると、他の正常なホスト(上記の場合は左右ホスト)が仮想マシンを自動的に再度稼働させます。vSphere
はじめに vSphere HA(High Availability)とは、vSphere 環境の可用性を高める機能の一つであり、共有ストレージを使用する大きなメリットでもある。公式ドキュメントやブログ等において、既に多くの解説がなされている機能ではあるものの、日本語で詳細に踏み込んだ記事も少なく、基本的な機能でありながら難しい部分も含むため、本記事を書くことにした。 機能概要 vSphere HA は、簡単に言うと、ESXi ホストの障害発生時に、そのホスト上で稼働していた仮想マシンを別のホスト上に再起動させる機能である。1 これにより、管理者はESXi ホスト障害の際に、手動でのオペレーションをすることなく、かつ仮想マシンのダウンタイムを最小化することができる。仮想マシンの再起動中は当然ながらサービスは停止するものの、自動かつ最速でサービスを復旧させてくれるので、管理者にとってもユーザー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く