[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Creating a vm with a non-existent /dev/mapper/ tap2 device effectively hangs dom0 system


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Nathan March <nathan@xxxxxx>
  • Date: Wed, 27 Jul 2011 16:29:59 -0700
  • Delivery-date: Wed, 27 Jul 2011 16:30:53 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=mail; b=erN8B0d+H5rey4L6sRz EMYJAqqlkTwV46C5QYoQ+q6DVCbs+8WmmN7J/OeHrkfPeVKS9cBVGYEcqz1SRG2u Ub9aZznLmg5CfrtKv8Z8yfZj0zZuY/sGpmGUq3ChUs6YdP7VWQYdKbXytRuCQzv7 wn7loS4iD/JT8hzUM42be1NI=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Have an interesting one here, originally found on xen 4.1.0 but just upgraded to xen 4.1.1 and it's still here.

Creating a VM with a tap2 device pointed at /dev/mapper/something, when that device doesn't exist, causes the tapdisk2 process to go into D mode and also manages to take out any process that queries it.

For example, I have /dev/mapper/nathanxenuk1 as a valid disk and /dev/mapper/test which doesn't exist. Creating using libvirt:

<opt type="xen">
<name>nathanxenuk1</name>
<devices>
<disk type="file">
<driver name="tap2" cache="default" type="aio" />
<source file="/dev/mapper/nathanxenuk1" />
<target dev="xvda" />
</disk>
<disk type="file">
<driver name="tap2" cache="default" type="aio" />
<source file="/dev/mapper/test" />
<target dev="xvdc" />
</disk>
<interface type="bridge">
<mac address="00:16:3E:10:00:01" />
<script path="/etc/xen/scripts/vif-bridge" />
<source bridge="vlan91" />
</interface>
</devices>
<memory>4194304</memory>
<os>
<bootloader>/usr/bin/pygrub</bootloader>
<type>linux</type>
</os>
<vcpu>12</vcpu>
</opt>

Results in:
libvirt error code: 11, message: POST operation failed: xend_post: error from xen daemon: (xend.err "Error creating domain: ('create', '-aaio:/dev/mapper/test') failed (512 )")

Normal so far and what I'd expect. At this point however doing anything that queries that tapdisk2 pid in /proc/ will fully hang.

Doing an "strace -f ps auxf &" (Backgrounding so I can keep my console), it ends here and I can find the pid causing it:

open("/proc/11327/status", O_RDONLY)    = 6
read(6, "Name:\ttapdisk2\nState:\tD (disk sl"..., 1023) = 706
close(6)                                = 0
open("/proc/11327/cmdline", O_RDONLY)   = 6
read(6,

Trying to do almost anything against /proc/11327/ results in a hang, but I can see the FD's ok:

ukxen2 ~ # cd /proc/11327
ukxen2 11327 # ls -al &
[2] 12144

ukxen2 11327 # cd fd
ukxen2 fd # ls -al &
[3] 12211
ukxen2 fd # total 0
dr-x------ 2 root root  0 Jul 27 16:24 .
dr-xr-xr-x 7 root root  0 Jul 27 16:16 ..
lrwx------ 1 root root 64 Jul 27 16:27 0 -> /dev/null
lrwx------ 1 root root 64 Jul 27 16:27 1 -> /dev/null
lrwx------ 1 root root 64 Jul 27 16:27 2 -> /dev/null
lrwx------ 1 root root 64 Jul 27 16:27 3 -> socket:[39528]
lrwx------ 1 root root 64 Jul 27 16:27 4 -> anon_inode:[eventfd]
lrwx------ 1 root root 64 Jul 27 16:27 5 -> socket:[39531]
lrwx------ 1 root root 64 Jul 27 16:27 6 -> socket:[40730]
[3]+  Done                    ls --color=auto -al
ukxen2 fd #

And /proc/11327/status works:

ukxen2 11327 # cat status &
[3] 12236
ukxen2 11327 # Name:    tapdisk2
State:  D (disk sleep)
Tgid:   11327
Pid:    11327
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 64
Groups:
VmPeak:    23056 kB
VmSize:    21644 kB
VmLck:     21640 kB
VmHWM:      3848 kB
VmRSS:      3232 kB
VmData:      364 kB
VmStk:        88 kB
VmExe:       224 kB
VmLib:      2460 kB
VmPTE:        64 kB
Threads:        1
SigQ:   2/6081
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000181000242
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed:   1
Cpus_allowed_list:      0
Mems_allowed:   1
Mems_allowed_list:      0
voluntary_ctxt_switches:        4155
nonvoluntary_ctxt_switches:     3559

Even doing an ls or trying to use tab completion in /proc/11327/ will result in your proc going into D mode.

Any existing VM's stay running fine and I can manage them remotely via libvirt, so only the dom0 is affected.

Any ideas? =)

Thanks,
Nathan

--
Nathan March<nathan@xxxxxx>
Gossamer Threads Inc. http://www.gossamer-threads.com/
Tel: (604) 687-5804 Fax: (604) 687-5806


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.