Bug 213611 - the second DomVTi cannot work and Dom0 becomes hang
the second DomVTi cannot work and Dom0 becomes hang
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
ia64 Linux
high Severity urgent
: ---
: ---
Assigned To: Aron Griffis
: 213620 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-11-02 05:18 EST by Watanabe Takehiko
Modified: 2010-10-22 02:46 EDT (History)
3 users (show)

See Also:
Fixed In Version: 5.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-11 22:00:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Watanabe Takehiko 2006-11-02 05:18:19 EST
Description of problem:
I'm using Milestone 7 on our PRIMEQUEST 580 and 520. I attmpted to create
multiple VTi  domains on my vncviewer.
The first domain was succesfully created, but the second domain did't start a
qemu window. But xm list show the second domain.
So I tried "xm console" to connect it, but the following message was returned
after few seconds.

 xenconsole: Could not read tty from store: No such file or directory

Then I terminated the second domain by "xm shutdown" and tried creating it, but
the result was same.  
And then, Domain0 became hang after 8 or 9 times of trying.

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
1. xm create <configfile for the first domain>
2. xm create <configfile for the second domain>  
3. xm console <the second domain>
4. xm shutdown <the second domain>
5. Repeat the step 2-4. 
Actual results:
A qemu window is not created.
the following message was returned.
 "xenconsole: Could not read tty from store: No such file or directory"
Domain0 becomes hang.

Expected results:
A qemu window for the second domain is created.
The second domain can be managed by "xm console".
More domains can  be created.

Additional info:
Here is my config file for reference.

#  -*- mode: python; -*-

import os, re
arch = os.uname()[4]
arch_libdir = 'lib'

kernel = "/boot/Flash.fd"
memory = 512
name = "rhel4-vti2"
disk = [ 'file:/xen/image/rhel4u4_full_02.img,ioemu:hda,w' ]
device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'
memmap = '/usr/lib/xen/boot/mem-map.sxp'
Comment 1 Stephen Tweedie 2006-11-02 06:41:53 EST

 "xenconsole: Could not read tty from store: No such file or directory"

error is an selinux problem and should be fixed in
selinux-policy-targeted-2.4.2-3 or later.

Can you please try reproducing with a new selinux policy and see if the other
dom0 hang problem persists?  Thanks.
Comment 2 Stephen Tweedie 2006-11-02 06:46:29 EST
*** Bug 213620 has been marked as a duplicate of this bug. ***
Comment 3 Atsushi SAKAI 2006-11-02 09:34:07 EST

But when that package version is available as a milestone?
Comment 4 Atsushi SAKAI 2006-11-07 03:15:20 EST
Please give me selinux-policy-targeted-2.4.2-3 sooner.
We want to confirm this bug will fix.

Comment 5 Atsushi SAKAI 2006-11-07 04:05:12 EST
Why selinux-policy-targeted needed even in SELinux=off?
Comment 10 Masahiro Matsuya 2006-11-10 08:25:35 EST
The result from Fujitsu. I'll have them provide the sysreport, the files in
/var/log/xen, and /var/log/audit/audit.log.

We are testing the package.
And We confirmed that dom0 hang issue is solved.

But, after 10 times trying, we saw  a message as follows,

xenconsole: Could not read tty from store: No such file or directory

Is there any solution to solve this message.

Configuration is as follows .
# rpm -qa | grep selinux

# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.

# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.

# SETLOCALDEFS= Check local definition changes

Watanabe Takehiko
SAKAI Atsushi
Comment 11 Masahiro Matsuya 2006-11-13 14:17:53 EST
Created attachment 141087 [details]
sysreport when this issue occurred
Comment 12 Masahiro Matsuya 2006-11-13 14:19:56 EST
Created attachment 141089 [details]
log files related with xen

Comment 13 Issue Tracker 2006-11-13 14:23:32 EST
From IT:

Sakai-san, Watanabe-san,
Could you please provide the files in the directory '/var/log/xen',
/var/log/audit/audit.log, and the sysreport of the system just after this
issue occurs?

I tried the same test again today.
And the message was displayed on the sixth attempting,

Here is the files under /var/log/xen and the sysreport at that time.
(The /var/log/audit/audit.log was not created.)


Watanabe Takehiko
SAKAI Atsushi

This event sent from IssueTracker by mmatsuya 
 issue 106338
Comment 15 RHEL Product and Program Management 2006-11-15 10:02:03 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
Comment 16 Larry Troan 2006-11-20 13:41:48 EST
Per discussion with Prarit and Aron,
Bug 213611...
> > Aron: I will also say that anything that doesn't have a patch yet will not 
> > make RC.
>   Status-ASSIGNED to Aron Griffis, no patch
Fix deferred to 5.1 assuming a patch exists and is accepted upstream in time.

Changing flags to 5.1 and raising Priority.
Comment 19 Aron Griffis 2007-04-11 22:00:27 EDT
Everything in this bug was resolved in RHEL5 GA.  The two problems reported here
were xenconsole/selinux issue, and errors starting HVM domains.

Regarding the first, it was fixed by selinux-policy-targeted-2.4.2-3

Regarding the second, it was fixed by the myriad of xen/ia64 patches that landed
prior to RHEL5 GA.  I tested by doing:

for ((i=0;i<100;i++)); do 
  echo "### $i ###"
  xm create hvm_rhel5_c0d1p1 && \
  xm create hvm_rhel5_c0d1p4 && \
  sleep 5 && xm list && \
  xm shutdown hvm_rhel5_c0d1p1 && \
  xm shutdown hvm_rhel5_c0d1p4 && \
  sleep 5 || break

This ran to completion successfully.

Note You need to log in before you can comment on or make changes to this bug.