akayuki による投稿:

PC環境はCPU　AMD　Athlon６４X2　Dualcore５２００
マザーボードASUS M2NPV-VM

VirtualBoxで起動する前に、Windows側のNVIDIAチップセットドライバをアンインストールしなければならないかもしれません。

akayukiさんのWindows環境にもNVIDIAのチップセットドライバをマザーボード付属CDだったりNVIDIAサイトからのダウンロードで
入れていると思います、勘ですがそれらが入っていると起動しないように思います。
※・・・という事は結論として仮想PCと実環境を行き来するのにいちいちドライバを入れたり出したりする事になるので、実用上の意味はほとんどない状況です。

おそらくWindows側に
NVIDIA nForce Networking Controller や NVIDIA Network Bus Enumerator など NVIDIAから始まる名前のデバイスがデバイスマネージャで
いくつか見つかると思うのですが、それらをひとつずつ使用停止したり削除して試してみる、を繰り返すしかないかもしれません。

「NVIDIAチップセットのPCで使っていたシステムHDDを、IntelチップセットのPCに付け替え、再インストールすることなくスムーズにPCを引っ越す、またその逆を行う一般的な方法」
があれば、おそらくそれを行う事でうまくいくのでは・・・と思いますが、申し訳ないです私にはわかりかねます。
※私はチップセットメーカーの違うPCでWindowsシステムHDDの付け替え引っ越しに成功した事がありません・・・。

いずれにせよ 例の「Windows　を通常起動」が出たということは、そこから先はWindowsの問題となります。

akayuki による投稿:

何か凄いですね。単純な質問で恐縮ですが、windowsが.vmdkファイルにあるときだけの問題ですか？.vdiでは問題ないのですか？

問題の有り無しは、新規に入れたWindowsかそうでないか、に拠ります。仮想ディスクファイルの種類は直接関係しません。

.vdi の仮想ディスクファイルの場合、通常 .vdi の中に新規にOSをCDやISOイメージからインストールしているはずです。
新規インストールのWindowsであれば、インストールし立ての時は汎用ドライバしか入っていないので(当然)起動しますし、その後も
そのPC(実機、仮想問わず)専用のドライバしか入れないので問題は起きません。

例えば今、akayukiさんの仮想PC(HDDが実ドライブを仮想化したvmdk)に、HDDの中身をフォーマットして(実際に実ドライブデータが消える)
CDからWindowsXPを新規にインストールした場合、実ドライブに仮想PCでセットアップしたWindowsが入っていますので
これはVirtualBoxで難なく起動するはずです。
※逆に、そのWindowsは実環境では起動しないかもしれない。

.vmdk は VMwareが標準採用しているファイル形式で、今回のような実ディスクを仮想的に登録する以外に、.vdiのようにそれなりのサイズを持った仮想ディスクファイルとしても作れます、
もちろんその中に新規に入れたWindowsは何の問題もなく使えます。
※例えば、VMware上でインストールしたWindowsの入った.vmdkファイルをVirtualBoxで起動したら、VMwareとVirtualBoxで作られる仮想PCのスペックは違うので
※問題が起こったりする可能性は考えられます。

akayuki による投稿:

によりますと、例えば（意味ないかもしれませんが）他のpartitionにインストールしてあるfedora10なんかも呼び出し可能なのですか？

Fedoraのパーティションを仮想ディスク登録して、適切な手段を踏めば起動でき、快適に使えます。
カーネルが呼び出せれば(まず間違いなく)一発で起動はします。
今回の件は、語弊がありますがあえて言えば、環境の引っ越しに弱いWindowsに限って起こっている問題です。

仮想PCから実HDDに直接読み書きが出来る事を利用して、こんな事をやった経験があります。

・それなりに速くてメモリもあるデスクトップPC
・年代モノで256MBしかメモリがなくて、Ubuntu日本語リミックスCDがLiveCD起動できないノート

があるとします。

・ノートのHDDを取り出して、USB外付けHDDケースに詰め、デスクトップPCに接続
・デスクトップPCで仮想マシンを構築し、外付けHDDのディスク全体(パーティションでなく)を仮想マシンのディスクとして登録
・仮想マシンでUbuntu日本語リミックスCDをLiveCD起動
・好き放題パーティションを区切ったりインストールをしたり、ある程度設定もしたり、自由に使う。デスクトップPCはノートよりスペックが高いので作業が速い。
・ひとしきり終えたら、ケースからHDDを取り出してノートに詰めて起動。先程の続きを実環境で。

また、VirtualBox等仮想PCソフトはWindows版もありますので、逆にWindows起動して実HDDのUbuntuを仮想PCで扱っても良いかもしれません。
その際は、Ubuntu側で高性能グラフィックドライバを使わないようにしておきます。
※プロプライエタリなグラフィックドライバを使っていると、Xの設定ファイルが決め打ちされるので「Windowsが黒画面」と似たような理由でXの起動に失敗する可能性があります。

思い直し馬鹿を承知で実行mode７７７にしてみたらあの嫌な
ＧＲＵＢ　ＬｏａｄｉｎｇStage 1,5
Grub　loading,please　wait...ERROR17
が出ます。
再度起動すると以下が出ます。
仮想マシン"ubuntusv"の起動に失敗しました。
VD: error opening image file '/home/user/.VirtualBox/ubuntusv.vmdk' (VERR_ACCESS_DENIED).
Failed to open image '/home/user/.VirtualBox/ubuntusv.vmdk' in read-write mode rc=VERR_ACCESS_DENIED (VERR_ACCESS_DENIED).
Failed to attach driver below us! Access denied. (VERR_ACCESS_DENIED).
Unknown error creating VM (VERR_ACCESS_DENIED).

最後の編集者: akayuki (2009-05-24 21:58:56)

改めてやりました。
sudo　chmod　666　/dev/sda　sudo　chmod　666　/dev/sda7
.VirtualBoxは必要ないので＄　VBoxManage internalcommands createrawvmdk -filename /a/user/ubntusv.vmdk -rawdisk /dev/sda　-partitions　７　-register　としました。

a@a:~$ cd /home/a
a@a:~$ ls
examples.desktop  ubuntusv.vmdk  音楽  公開  動画
ubuntusv-pt.vmdk  デスクトップ   画像  雛形  文書

a@a:~$ df
ファイルシステム           1K-ブロック    使用   使用可 使用% マウント位置
/dev/sda6             57677500   3522564  51225084   7% /
tmpfs                  1806880         0   1806880   0% /lib/init/rw
varrun                 1806880       104   1806776   1% /var/run
varlock                1806880         0   1806880   0% /var/lock
udev                   1806880       148   1806732   1% /dev
tmpfs                  1806880       476   1806404   1% /dev/shm
lrm                    1806880      2392   1804488   1% /lib/modules/2.6.28-11-generic/volatile

の状態でVirtualBoxから新規で作成し起動しました。勿論アクセスに失敗していますが、表示がちょっと変わりました。

仮想マシン"uuu2"の起動に失敗しました。
Medium '/home/a/ubuntusv.vmdk' is not accessible. Could not open the hard disk '/home/a/ubuntusv.vmdk'.
VD: error opening image file '/home/a/ubuntusv.vmdk' (VERR_ACCESS_DENIED).

尚この他の操作はしていません。現状報告です。
どうも根本的な知識不足のようですですね。すみません。

最後の編集者: akayuki (2009-05-25 13:58:57)

お伝えしている情報、homeとかaとかコピペミス等実にいいかげんでした。今後十分注意します。前回経験しているのにdisk グループ参加をしていませんでした。仮想ディスクの登録は出来ていましたので
ＧＲＵＢ　ＬｏａｄｉｎｇStage 1,5
Grub　loading,please　wait...ERROR17
迄到達できました。第一関門突破しました。
さて次はすっきりしているPBR吸い出しのやりかた、０～３に従い無事grubメニュー選択でトップを選択。
starting up ...

ところがThis kernel requires the following features not present on the CPU:pae
enable to boot- please use a kernel appropriate for your CPU.
と出ました。でもこれでVirtualBoxの方は解決ですね。嬉しいです。
尚マルチbootgrubから選択のサーバーでは問題ありません。又本題から外れてしまいそうです。pae？

最後の編集者: akayuki (2009-05-25 18:09:22)

杞憂でした。「sda7のUbuntuを実機で起動」...こういった表現、私には絶対できないです。
万歳完成です。「デュアルブートだけど仮想マシンっぽく」に初質問参加させていただいたのが5月18日、今日が25日、この一週間実に充実していました。益々linuxが楽しくなりました。スレ主veraveraさん、皆様、ありがとうございました。
ackさん本当にありがとうございました。

akayuki による投稿:

一夜明けて、次は
「例えば今、akayukiさんの仮想PC(HDDが実ドライブを仮想化したvmdk)に、HDDの中身をフォーマットして
～略～
※逆に、そのWindowsは実環境では起動しないかもしれない」....5月18日
をやってみようと思います。

うまく行くことをお祈り致します。
ひとつ注意点として、Windowsをインストールするディスクを登録する際に、例のごとくMBR用のファイル(今回は空っぽの512バイトのファイルであれば良い)を一緒に登録しておいて下さい。
そのままだとWindowsのインストーラがMBRに書き込みを行うので、仮想ディスクに登録を行っていない範囲(パーティションでなくディスクの先頭)に書き込みを行おうとし、
(もちろん書き込めないので)Windowsのインストールに失敗すると思われます。

akayuki による投稿:

VirtualBoxのグループ名がdiskであることをどうやって探る、解るかを教えていただきたいと思います。linuxの基本の基本なのだろうとは思いますがよろしくお願い致します。

正確には
「VirtualBoxを実行しようとしている自分のユーザアカウントが、diskグループに参加すると、自分が実行したVirtualBoxが実ディスクを扱える」という事です。
どのようにたどり着いたか書き出しますので参考になれば・・・

VirtualBoxがアクセス権に関するエラーを出した
↓
今回実ディスクを扱おうとしているので、実ディスクを読み書きする権限がないのかもしれない
↓
実ディスクは /dev の中に sdなにそれ と出てくる。1台目のディスクは sda となる。パーティションはその後に番号が付く
↓
よし /dev/sda の所有権など確認してみよう

ls -l /dev/sda*

※例えばこんなのが出たとします
brw-rw---- 1 root disk 8, 0 2009-05-27 01:07 /dev/sda
brw-rw---- 1 root disk 8, 1 2009-05-26 16:07 /dev/sda1
brw-rw---- 1 root disk 8, 2 2009-05-27 01:07 /dev/sda2
brw-rw---- 1 root disk 8, 5 2009-05-27 01:07 /dev/sda5

/dev/sdaの各ファイル(＝生の実ディスク)は
・root が所有者のファイル
・disk グループ所属のファイル
・所有者とグループ参加者が読み書き、他は権限なし
の模様
※
http://www.pinkdragon.net/DocumentsLibrary/contents/ja/Linux_man/ls.1.html
http://ja.wikipedia.org/wiki/Ls_%28UNIX%29
他ネット内の多数の資料参照
↓
diskグループに所属しているアカウントなら/dev/sdaの各ファイルが読み書きできるようだ
↓
アプリは実行したアカウントの権限で動作する。VirtualBoxも然り。
↓
よし自分のユーザアカウントをdiskグループに参加させよう

と言った感じです。

途中経過です。

HDD構成　　279.46GB
/dev/sda1　ntfs　　　windowsｘｐ
/dev/sda2　extended
/dev/sda5　swap
/dev/sda6　　ext3　　ubuntu9.04ディスクトップ
/dev/sda7　　ext3　　ubuntu9.04サーバー
この後ろに/dev/sda3     ntfs    基本パーティションを作成
$ sudo apt-get install mbr
$ dd if=/dev/zero of=winxpb.mbr bs=512 count=1
$ VBoxManage internalcommands createrawvmdk -filename /home/a/winxpb.vmdk -rawdisk /dev/sda -partitions 3 -mbr /home/a/winxpb.mbr -register
winxpb.vmdk を使った仮想PCを作って起動。
インストールがごく普通に始まったのですが、インストールパーティション選択で、ちょっと危険を感じ一時ストップ状態です。臆病になっていますので（サーバーの時は気になりませんでしたが、既存のwindowXp消したくないので。）すみません。
後ほど又報告します。

最後の編集者: akayuki (2009-05-26 22:06:23)

とんちんかんを覚悟ですが、「後ろに/dev/sda3     ntfs    基本パーティションを作成」　したのが余計で、空き領域にインストール先を指定すればいいのかも？

akayuki による投稿:

この後ろに/dev/sda3     ntfs    基本パーティションを作成
$ sudo apt-get install mbr
$ dd if=/dev/zero of=winxpb.mbr bs=512 count=1
$ VBoxManage internalcommands createrawvmdk -filename /home/a/winxpb.vmdk -rawdisk /dev/sda -partitions 3 -mbr /home/a/winxpb.mbr -register

既存のパーティション、sda7の後ろにsda3が出来る形になっていますが、
https://forums.ubuntulinux.jp/viewtopic.php?pid=29762#p29762
にあるような「ディスクの先頭から番号が振られていないとコマンドが失敗する」にはなりませんでしたか？
※でもインストール作業が続けられているのでうまく行っているのか・・・制限は論理パーティションの番号だけ？

akayuki による投稿:

インストールしたいsda3　（D:パーティション２　と表示されています）を選択したところ次の画面でsda1　（C:パーティション１　と表示されています）に急に変わります。
「このままだとWindowsのインストーラがMBRに書き込みを行うので、仮想ディスクに登録を行っていない範囲(パーティションでなくディスクの先頭)に書き込みを行おうとし]....とのことですが、まさにこの状態になりました。
「ひとつ注意点として、Windowsをインストールするディスクを登録する際に、例のごとくMBR用のファイル(今回は空っぽの512バイトのファイルであれば良い)を一緒に登録しておいて下さい。」...この解釈、操作を私が間違っているのでしょうか？

ここまでは合っていると思います。
VirtualBox の createrawvmdk で実ディスクの一部のパーティションを登録すると、「ディスク全体としては物理ディスクのパーティションテーブルやサイズをそのまま認識するが、-partitions で指定したパーティション以外は何故か読み書きができず中身が0で埋まっているもの」として仮想PCに登録されます。
-partitions 3 しか登録していないはずなのに、仮想メディアマネージャで物理ディスク丸ごとのサイズが登録されたり、Windowsインストール中のパーティション選択画面で、既存のntfsや不明領域(ext3)などが見えたりしていたと思いますが、それはこれが原因です。

※VMwareの仮想PCを実環境扱いにして、その中にさらにVirtualBoxを入れての実験ですが、-partitions で登録されていない領域は仮想PC内のUbuntuからはrootでも書き込めず読んでも0しか出てこず、rootのfdiskで登録外のパーティションを消そうとしてもioctlに失敗するので実ディスクに影響を及ぼす事が出来ない、という事は確認しました。

確認は取っていませんが、例えばMBR用のファイルなしでWindowsのインストールを続行した場合、Windowsインストーラは物理ディスク全体が見えてはいるので、ディスクの先頭にMBRを入れようとするが、「-partitions で指定したパーティション以外は何故か読み書きができず」のためMBRの書き込みに失敗するはずです。

なので、書き込みできるディスクの先頭のフリをしてくれるMBR用ファイルを用意したらうまく行くのでは・・・という発想です。
申し訳ございません、Windowsのドライブレターの振り方と起動ディスクの関係が私はちゃんと理解できていないので、次の画面でD:を選択したらC:と出てくるのが
・本当にsda3でなくsda1を指している
・Windows的にOSが入るのはC:なので、このタイミングでsda3をC:とする事になっている(こんな挙動だったような気もする・・・)
のどちらの状況になっているのかわかりません。
仮にsda3でなくsda1を指しているとしても、VirtualBoxの中からはsda1部分は「何故か読み書きができず」のため何も書き込めずWindowsインストーラがコケる→sda1のWindowsは無事、に落ち着いてくれるとは思うのですが、申し訳ございません未確認のため断言は出来ません・・・。

「Windows的にOSが入るのはC:なので、このタイミングでsda3をC:とする事になっている(こんな挙動だったような気もする・・・)」
全くこの通りですね。