XM 创建时遇到一些问题
我对 Xen 有一点问题。每次我尝试运行 xm create 时，都会收到以下错误：
dom0:~# xm create -c staros.xm
Using config file "./staros.xm". Started domain StarOS-3 xenconsole: Could not read tty from store: No such file or directory
这对任何人来说都很熟悉吗？
我相信我的配置是正确的。起初我怀疑 qemu-dm 的路径设置不正确。
I have a bit of a problem with Xen. Each time I try to run xm create I get the following error:
dom0:~# xm create -c staros.xm
Using config file "./staros.xm". Started domain StarOS-3 xenconsole: Could not read tty from store: No such file or directory
Is this familiar to anyone?
I believe my config is in order. At first I suspected the path to qemu-dm wasn't set correctly.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您描述的错误可能意味着两件事：
它正在记录 xenstore 中众所周知的竞赛
附加到域控制台所需的伪 TTY 存储在 xenstore 中的多个位置。 Xen 控制台客户端对该值建立 inotify 样式监视，以便在支持文件描述符发生更改时它可以重新连接到控制台。但是，从最初创建域时起，该信息需要几秒钟的时间才能填充到 xenstore 中。
如果您发布 xm info 的输出，就很容易看出您是否正在处理一场众所周知的比赛。
无法创建后备伪终端
常见原因是 /dev/pts 未安装。如果在不使用
-c选项启动域后运行xenstore-ls /local/domain/{domain_id}，您将看到该域的存储内容。 的行（靠近底部）查找显示“验证 pty 确实存在”
。 xen 控制台守护进程使用两个实际的文件描述符来实现这一点。第一个是节点中特定信息的伪文件描述符（通过 xs_fileno() 获得），因此它可以 poll() 来查看该信息是否发生变化。第二个是从
open()返回的真实 FD（是的，传递了 O_NONBLOCK），它实际上读取/写入 psuedo tty。看起来它甚至没有从 xenstore 找到伪 FD，这意味着支持 pty 可能面临生存挑战。
The error you are describing could mean two things:
It is documenting a well known race in xenstore
The psuedo TTY needed to attach to a domain's console is stored in xenstore in several places. The Xen console client establishes an inotify style watch on that value, so that it can reconnect to the console if the backing file descriptor happens to change. However, takes a few seconds for that information to be populated in xenstore from the time that the domain is initially created.
If you post the output of xm info, it would be easy to see if you are dealing with a well known race.
The backing psuedo terminal can't be created
Common reasons for this would be /dev/pts not being mounted. If you run
xenstore-ls /local/domain/{domain_id}after starting the domain without the-coption, you will see the contents of the store for that domain. Look for the line (near the bottom) that saysVerify that the pty does, in fact, exist.
The xen console daemon uses two actual file descriptors to make it happen. The first is a psuedo file descriptor (obtained via xs_fileno()) on that specific piece of information in the node, so it can poll() to see if that information changes. The second is a real FD returned from
open()(yes, O_NONBLOCK is passed) which actually reads/writes to the psuedo tty.It looks like it's not even finding the psuedo FD from xenstore, which means the backing pty is likely existentially challenged.