VHD BUG in xen4.0 when install windows2008

VHD BUG in xen4.0 when install windows2008

[yingbin wang]

[-- Attachment #1.1: Type: text/plain, Size: 3275 bytes --]

Description of problem:
after install Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G,
D:\ 5G) on vhd file (as base image), os can not startup.
I found data error in C:\Windows\System32 :
?--------- ? ?    ?           ?            ? pnpts.dll
?--------- ? ?    ?           ?            ? pnpui.dll
?--------- ? ?    ?           ?            ? PnPUnattend.exe
?--------- ? ?    ?           ?            ? PnPutil.exe

How reproducible:
I tested 10 times, it appear 10 times that os can not startup.

Steps to Reproduce:
1. vhd-util create -n test.vhd -s 20480
2. xm create test.hvm
3. install Windows 2008 R2 Standard Edition 64 ( disk size: 20G, C:\ 15G,
D:\ 5G )
4. can not startup
5. xm des test.vhd
6. tapdisk2 -n vhd:/mnt/img/test.vhd
7. mount -o offset=105906176 -t ntfs /dev/xen/blktap-2/tapdev0 /mnt/vhd
8. ll /mnt/vhd/Windows/System32 | grep ?
?--------- ? ?    ?           ?            ? pnpts.dll
?--------- ? ?    ?           ?            ? pnpui.dll
?--------- ? ?    ?           ?            ? PnPUnattend.exe
?--------- ? ?    ?           ?            ? PnPutil.exe

Additional info:
I install
Windows 2003 Standard Edition SP1 32(disk size: 50G, C:\50G) on vhd file,
the problem disappear.
Redhat 5.4 AS 64(disk size:60G, /: 50G, swap: 10G) on vhd file, the problem
disappear.
Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 100G) on vhd file,
the problem disappear.
Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 90G, D:\10G)
on vhdfile, the problem
disappear.
Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G)
on rawfile, the problem
disappear.
Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G)
on vhd file,
the problem appear.
Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 15G, D:\85G)
on vhdfile, the problem
appear.

ps:
windows 2003 need 3G disk space.
redhat 5.4 need 4G disk space.
windows 2008 need 8G disk space.
the problem disappear means that os can startup and no data error.

compile env and filesystem :
 Redhat AS 5.4

xm info:
host                   : vm01
release                : 2.6.31.13
version                : #1 SMP Wed Apr 21 12:30:21 CST 2010
machine                : x86_64
nr_cpus                : 16
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 2
cpu_mhz                : 2400
hw_caps                :
bfebfbff:28100800:00000000:00001b40:009ce3bd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 24539
free_memory            : 1668
node_to_cpu            : node0:0-15
node_to_memory         : node0:1668
node_to_dma32_mem      : node0:82
max_node_id            : 0
xen_major              : 4
xen_minor              : 0
xen_extra              : .0
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : dom0_max_vcpus=2 dom0_vcpus_pin
cc_compiler            : gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
cc_compile_by          : root
cc_compile_domain      : dev.sd.test.com
cc_compile_date        : Mon Apr 26 10:17:37 CST 2010
xend_config_format     : 4

[-- Attachment #1.2: Type: text/html, Size: 4644 bytes --]

[-- Attachment #2: test.hvm --]
[-- Type: application/octet-stream, Size: 13913 bytes --]

#  -*- mode: python; -*-
#============================================================================
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm create'.
# You use a separate script for each domain you want to create, or 
# you can set the parameters for the domain on the xm command line.
#============================================================================

import os, re

arch_libdir = 'lib'
arch = os.uname()[4]
if os.uname()[0] == 'Linux' and re.search('64', arch):
    arch_libdir = 'lib64'

#----------------------------------------------------------------------------
# Kernel image file.
kernel = "/usr/lib/xen/boot/hvmloader"

# The domain build function. HVM domain uses 'hvm'.
builder='hvm'

# Initial memory allocation (in megabytes) for the new domain.
#
# WARNING: Creating a domain with insufficient memory may cause out of
#          memory errors. The domain needs enough memory to boot kernel
#          and modules. Allocating less than 32MBs is not recommended.
memory = 1024

# Shadow pagetable memory for the domain, in MB.
# If not explicictly set, xend will pick an appropriate value.  
# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
# shadow_memory = 8

# A name for your domain. All domains must have different names.
name = "test.vhd"

# 128-bit UUID for the domain.  The default behavior is to generate a new UUID
# on each call to 'xm create'.
#uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"

#-----------------------------------------------------------------------------
# The number of cpus guest platform has, default=1
vcpus=2

# Enable/disable HVM guest PAE, default=1 (enabled)
#pae=1

# Enable/disable HVM guest ACPI, default=1 (enabled)
#acpi=1

# Enable/disable HVM APIC mode, default=1 (enabled)
# Note that this option is ignored if vcpus > 1
#apic=1

# Enable/disable extended power management support within HVM guest, i.e., beyond
# S3, S4, S5 within guest like exposing battery meter.
# 0 (default option, extended power management support disabled)
# 1 (pass-through mode; uses pass-through as needed; efficient but limited in scope)
# 2 (non pass-through mode; extended scope, likely to work on all applicable environment
#    but comparitively less efficient than pass-through mode)
# xen_extended_power_mgmt=0

# List of which CPUS this domain is allowed to use, default Xen picks
#cpus = ""         # leave to Xen to pick
#cpus = "0"        # all vcpus run on CPU0
#cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3

# Optionally define mac and/or bridge for the network interfaces.
# Random MACs are assigned if not given.
#vif = [ 'type=ioemu, mac=00:16:3e:00:00:11, bridge=xenbr0, model=ne2k_pci' ]
# type=ioemu specify the NIC is an ioemu device not netfront
vif = [ 'bridge=xenbr0,mac=00:16:3e:ef:00:03,vifname=ef0003' ]

#----------------------------------------------------------------------------
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.

#disk = [ 'phy:hda1,hda1,r' ]
disk = [ 'tap:vhd:/mnt/img/test.vhd,hda,w', 'file:/mnt/wyb/iso/windows_2008_64.std.iso,hdc:cdrom,r' ]

#----------------------------------------------------------------------------
# Configure the behaviour when a domain exits.  There are three 'reasons'
# for a domain to stop: poweroff, reboot, and crash.  For each of these you
# may specify:
#
#   "destroy",        meaning that the domain is cleaned up as normal;
#   "restart",        meaning that a new domain is started in place of the old
#                     one;
#   "preserve",       meaning that no clean-up is done until the domain is
#                     manually destroyed (using xm destroy, for example); or
#   "rename-restart", meaning that the old domain is not cleaned up, but is
#                     renamed and a new domain started in its place.
#
# In the event a domain stops due to a crash, you have the additional options:
#
#   "coredump-destroy", meaning dump the crashed domain's core and then destroy;
#   "coredump-restart', meaning dump the crashed domain's core and the restart.
#
# The default is
#
#   on_poweroff = 'destroy'
#   on_reboot   = 'restart'
#   on_crash    = 'restart'
#
# For backwards compatibility we also support the deprecated option restart
#
# restart = 'onreboot' means on_poweroff = 'destroy'
#                            on_reboot   = 'restart'
#                            on_crash    = 'destroy'
#
# restart = 'always'   means on_poweroff = 'restart'
#                            on_reboot   = 'restart'
#                            on_crash    = 'restart'
#
# restart = 'never'    means on_poweroff = 'destroy'
#                            on_reboot   = 'destroy'
#                            on_crash    = 'destroy'

#on_poweroff = 'destroy'
#on_reboot   = 'restart'
#on_crash    = 'restart'

#============================================================================

# Device Model to be used
device_model = 'qemu-dm'

#-----------------------------------------------------------------------------
# boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d) 
# default: hard disk, cd-rom, floppy
boot="dc"

#-----------------------------------------------------------------------------
#  write to temporary files instead of disk image files
#snapshot=1

#----------------------------------------------------------------------------
# enable SDL library for graphics, default = 0
sdl=0

#----------------------------------------------------------------------------
# enable OpenGL for texture rendering inside the SDL window, default = 1
# valid only if sdl is enabled.
opengl=1

#----------------------------------------------------------------------------
# enable VNC library for graphics, default = 1
vnc=1

#----------------------------------------------------------------------------
# address that should be listened on for the VNC server if vnc is set.
# default is to use 'vnc-listen' setting from /etc/xen/xend-config.sxp
vnclisten="0.0.0.0"

#----------------------------------------------------------------------------
# set VNC display number, default = domid
#vncdisplay=1

#----------------------------------------------------------------------------
# try to find an unused port for the VNC server, default = 1
#vncunused=1

#----------------------------------------------------------------------------
# set password for domain's VNC console
# default is depents on vncpasswd in xend-config.sxp
vncpasswd=''

#----------------------------------------------------------------------------
# no graphics, use serial port
#nographic=0

#----------------------------------------------------------------------------
# enable stdvga, default = 0 (use cirrus logic device model)
stdvga=0

#-----------------------------------------------------------------------------
#   serial port re-direct to pty deivce, /dev/pts/n 
#   then xm console or minicom can connect
serial='pty'


#-----------------------------------------------------------------------------
#   Qemu Monitor, default is disable
#   Use ctrl-alt-2 to connect
#monitor=1


#-----------------------------------------------------------------------------
#   enable sound card support, [sb16|es1370|all|..,..], default none
#soundhw='sb16'


#-----------------------------------------------------------------------------
#    set the real time clock to local time [default=0 i.e. set to utc]
#localtime=1


#-----------------------------------------------------------------------------
#    set the real time clock offset in seconds [default=0 i.e. same as dom0]
#rtc_timeoffset=3600

#-----------------------------------------------------------------------------
#    start in full screen
#full-screen=1   


#-----------------------------------------------------------------------------
#   Enable USB support (specific devices specified at runtime through the
#			monitor window)
#usb=1

#   Enable USB mouse support (only enable one of the following, `mouse' for
#			      PS/2 protocol relative mouse, `tablet' for
#			      absolute mouse)
#usbdevice='mouse'
usbdevice='tablet'

#-----------------------------------------------------------------------------
#   Set keyboard layout, default is en-us keyboard. 
#keymap='ja'

#-----------------------------------------------------------------------------
#   Enable/disable xen platform PCI device, default=1 (enabled)
#xen_platform_pci=1

#-----------------------------------------------------------------------------
#   Configure guest CPUID responses:
#
#cpuid=[ '1:ecx=xxxxxxxxxxx00xxxxxxxxxxxxxxxxxxx,
#           eax=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' ]
# - Unset the SSE4 features (CPUID.1[ECX][20-19])
# - Default behaviour for all other bits in ECX And EAX registers.
# 
# Each successive character represent a lesser-significant bit:
#  '1' -> force the corresponding bit to 1
#  '0' -> force to 0
#  'x' -> Get a safe value (pass through and mask with the default policy)
#  'k' -> pass through the host bit value
#  's' -> as 'k' but preserve across save/restore and migration
# 
#   Expose to the guest multi-core cpu instead of multiple processors
# Example for intel, expose a 8-core processor :
#cpuid=['1:edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx,
#          ebx=xxxxxxxx00010000xxxxxxxxxxxxxxxx',
#     '4,0:eax=001111xxxxxxxxxxxxxxxxxxxxxxxxxx']
#  - CPUID.1[EDX][HT] : Enable HT
#  - CPUID.1[EBX] : Number of vcpus * 2
#  - CPUID.4,0[EAX] : Number of vcpus * 2 - 1
vcpus=2
#
# Example for amd, expose a 5-core processor :
# cpuid = ['1:ebx=xxxxxxxx00001010xxxxxxxxxxxxxxxx,
#             edx=xxx1xxxxxxxxxxxxxxxxxxxxxxxxxxxx',
# '0x80000001:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1x',
# '0x80000008:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxx001001']
#   - CPUID.1[EBX] : Threads per Core * Cores per Socket (2 * #vcpus)
#   - CPUID.1[EDX][HT] : Enable HT
#   - CPUID.0x80000001[CmpLegacy] : Use legacy method
#   - CPUID.0x80000008[ECX] : #vcpus * 2 - 1
#vcpus=5
#
#  Downgrade the cpuid to make a better compatibility for migration :
# Look like a generic 686 :
# cpuid = [ '0:eax=0x3,ebx=0x0,ecx=0x0,edx=0x0',
#           '1:eax=0x06b1,
#              ecx=xxxxxxxxxxx0000xx00xxx0000000xx0,
#              edx=xxx00000xxxxxxx0xxxxxxxxx0xxxxxx',
#           '4:eax=0x3,ebx=0x0,ecx=0x0,edx=0x0',
#  '0x80000000:eax=0x3,ebx=0x0,ecx=0x0,edx=0x0']
#  with the highest leaf
#  - CPUID.0[EAX] : Set the highest leaf
#  - CPUID.1[EAX] : 686 
#  - CPUID.1[ECX] : Mask some features
#  - CPUID.1[EDX] : Mask some features
#  - CPUID.4 : Reply like the highest leaf, in our case CPUID.3
#  - CPUID.0x80000000 : No extension we are on a Pentium III, reply like the
#  highest leaf (CPUID.3).
#
#   Configure host CPUID consistency checks, which must be satisfied for this
#   VM to be allowed to run on this host's processor type:
#cpuid_check=[ '1:ecx=xxxxxxxxxxxxxxxxxxxxxxxxxx1xxxxx' ]
# - Host must have VMX feature flag set
#
# The format is similar to the above for 'cpuid':
#  '1' -> the bit must be '1'
#  '0' -> the bit must be '0'
#  'x' -> we don't care (do not check)
#  's' -> the bit must be the same as on the host that started this VM

#-----------------------------------------------------------------------------
#   Configure passthrough PCI{,-X,e} devices:
#
#   pci=[ '[SSSS:]BB:DD.F[,option1[,option2[...]]]', ... ]
#
#   [SSSS]:BB:DD.F  "bus segment:bus:device.function"(1) of the device to
#                   be assigned, bus segment is optional. All fields are
#                   in hexadecimal and no field should be longer than that
#                   as shown in the pattern. Successful assignment may need
#                   certain hardware support and additional configurations
#                   (e.g. VT-d, see docs/misc/vtd.txt for more details).
#
#       (1) bus segment is sometimes also referred to as the PCI "domain",
#           not to be confused with Xen domain.
#
#
#   optionN         per-device options in "key=val" format. Current
#                   available options are:
#                   - msitranslate=0|1
#                      per-device overriden of pci_msitranslate, see below
#                   - power_mgmt=0|1
#                      per-device overriden of pci_power_mgmt, see below
#
#pci=[ '07:00.0', '07:00.1' ]

#   MSI-INTx translation for MSI capable devices:
#
#   If it's set, Xen will enable MSI for the device that supports it even
# if the guest don't use MSI. In the case, an IO-APIC type interrupt will
# be injected to the guest every time a corresponding MSI message is
# received.
#   If the guest enables MSI or MSI-X, the translation is automatically
# turned off.
# 
#pci_msitranslate=1

#   PCI Power Management:
#
#   If it's set, the guest OS will be able to program D0-D3hot states of the
# PCI device for the purpose of low power consumption.
# 
#pci_power_mgmt=0

#-----------------------------------------------------------------------------
#   Configure PVSCSI devices:
#
#vscsi=[ 'PDEV, VDEV' ]
#
#   PDEV   gives physical SCSI device to be attached to specified guest
#          domain by one of the following identifier format.
#          - XX:XX:XX:XX (4-tuples with decimal notation which shows
#                          "host:channel:target:lun")
#          - /dev/sdxx or sdx
#          - /dev/stxx or stx
#          - /dev/sgxx or sgx
#          - result of 'scsi_id -gu -s'.
#            ex. # scsi_id -gu -s /block/sdb
#                  36000b5d0006a0000006a0257004c0000
#
#   VDEV   gives virtual SCSI device by 4-tuples (XX:XX:XX:XX) as 
#          which the specified guest domain recognize.
#

#vscsi = [ '/dev/sdx, 0:0:0:0' ]

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

RE: VHD BUG in xen4.0 when install windows2008

[Ian Pratt]

> Description of problem:
> after install Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G,
> D:\ 5G) on vhd file (as base image), os can not startup.

Which dom0 kernel is this with? I'm guessing one of Jeremy's pvops trees?

It might be worth reducing the number of dom0 VCPUs to 1 and repeating the experiment to see if that makes a difference. 

Thanks,
Ian


> I found data error in C:\Windows\System32 :
> ?--------- ? ?    ?           ?            ? pnpts.dll
> ?--------- ? ?    ?           ?            ? pnpui.dll
> ?--------- ? ?    ?           ?            ? PnPUnattend.exe
> ?--------- ? ?    ?           ?            ? PnPutil.exe
> 
> How reproducible:
> I tested 10 times, it appear 10 times that os can not startup.
> 
> Steps to Reproduce:
> 1. vhd-util create -n test.vhd -s 20480
> 2. xm create test.hvm
> 3. install Windows 2008 R2 Standard Edition 64 ( disk size: 20G, C:\ 15G,
> D:\ 5G ) 4. can not startup 5. xm des test.vhd 6. tapdisk2 -n
> vhd:/mnt/img/test.vhd 7. mount -o offset=105906176 -t ntfs
> /dev/xen/blktap-2/tapdev0 /mnt/vhd 8. ll /mnt/vhd/Windows/System32 | grep
> ?
> ?--------- ? ?    ?           ?            ? pnpts.dll
> ?--------- ? ?    ?           ?            ? pnpui.dll
> ?--------- ? ?    ?           ?            ? PnPUnattend.exe
> ?--------- ? ?    ?           ?            ? PnPutil.exe
> 
> Additional info:
> I install
> Windows 2003 Standard Edition SP1 32(disk size: 50G, C:\50G) on vhd file,
> the problem disappear.
> Redhat 5.4 AS 64(disk size:60G, /: 50G, swap: 10G) on vhd file, the
> problem disappear.
> Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 100G) on vhd
> file, the problem disappear.
> Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 90G, D:\10G) on
> vhd file, the problem disappear.
> Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
> raw file, the problem disappear.
> Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
> vhd file, the problem appear.
> Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 15G, D:\85G) on
> vhd file, the problem appear.
> 
> ps:
> windows 2003 need 3G disk space.
> redhat 5.4 need 4G disk space.
> windows 2008 need 8G disk space.
> the problem disappear means that os can startup and no data error.
> 
> compile env and filesystem :
>  Redhat AS 5.4
> 
> xm info:
> host                   : vm01
> release                : 2.6.31.13
> version                : #1 SMP Wed Apr 21 12:30:21 CST 2010
> machine                : x86_64
> nr_cpus                : 16
> nr_nodes               : 1
> cores_per_socket       : 4
> threads_per_core       : 2
> cpu_mhz                : 2400
> hw_caps                :
> bfebfbff:28100800:00000000:00001b40:009ce3bd:00000000:00000001:00000000
> virt_caps              : hvm
> total_memory           : 24539
> free_memory            : 1668
> node_to_cpu            : node0:0-15
> node_to_memory         : node0:1668
> node_to_dma32_mem      : node0:82
> max_node_id            : 0
> xen_major              : 4
> xen_minor              : 0
> xen_extra              : .0
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xffff800000000000
> xen_changeset          : unavailable
> xen_commandline        : dom0_max_vcpus=2 dom0_vcpus_pin
> cc_compiler            : gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
> cc_compile_by          : root
> cc_compile_domain      : dev.sd.test.com
> cc_compile_date        : Mon Apr 26 10:17:37 CST 2010
> xend_config_format     : 4
> 

Re: VHD BUG in xen4.0 when install windows2008

[yingbin wang]

[-- Attachment #1.1: Type: text/plain, Size: 5706 bytes --]

thank you for your reply.

as you guest, dom0 kernel: pvops 2.6.31.13

I try what you say.
menu.lst:
title Xen 4.0 kernel 2.6.31.13
        root (hd0,0)
        kernel /xen.gz dom0_mem=4096M dom0_max_vcpus=1 dom0_vcpus_pin
        module /vmlinuz-2.6.31.13 ro root=LABEL=/ nomodeset
        module /initrd-2.6.31.13.img

but the problem also appear, os can't startup.
Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G)
on vhdfile, the problem
appear.

when I install windows 2008, I meet another problem :
the dom0 hang up, I reboot the physical machine and found some info from
/var/log/message:
May  8 20:02:47 SS01 tapdisk2[21997]: Assertion
'list_empty(&vreq->next)' failed, line 1822, file tapdisk-vbd.c
May  8 20:02:47 SS01 kernel: tapdisk2[21997]: segfault at 0 ip
000000000040a24f sp 00007fff162b2d90 error 6 in tapdisk2[400000+39000]
May  8 20:02:47 SS01 kernel: blktap_device_fail_pending_requests:
252:2: failing pending write of 11 pages
May  8 20:02:47 SS01 kernel: end_request: I/O error, dev tapdevc,
sector 10485752
May  8 20:02:47 SS01 kernel: Buffer I/O error on device tapdevc,
logical block 1310719
May  8 20:02:47 SS01 kernel: lost page write due to I/O error on tapdevc
May  8 20:02:47 SS01 kernel: Buffer I/O error on device tapdevc,
logical block 1310720
May  8 20:02:47 SS01 kernel: lost page write due to I/O error on tapdevc
May  8 20:02:47 SS01 kernel: Buffer I/O error on device tapdevc,
logical block 1310721
May  8 20:02:47 SS01 kernel: lost page write due to I/O error on tapdevc

I don't know the relation between two problems.I hope it give you more info
to help me solve the problem.
I think it may be a bug of the pvops 2.6.31.13. I hope there is a way to
solve it. could you give some advise?
I will try xenlinux 2.6.18.8 and report the result.

Cheers,
wyb
2010/5/8 Ian Pratt <Ian.Pratt@eu.citrix.com>

> > Description of problem:
> > after install Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\
> 15G,
> > D:\ 5G) on vhd file (as base image), os can not startup.
>
> Which dom0 kernel is this with? I'm guessing one of Jeremy's pvops trees?
>
> It might be worth reducing the number of dom0 VCPUs to 1 and repeating the
> experiment to see if that makes a difference.
>
> Thanks,
> Ian
>
>
> > I found data error in C:\Windows\System32 :
> > ?--------- ? ?    ?           ?            ? pnpts.dll
> > ?--------- ? ?    ?           ?            ? pnpui.dll
> > ?--------- ? ?    ?           ?            ? PnPUnattend.exe
> > ?--------- ? ?    ?           ?            ? PnPutil.exe
> >
> > How reproducible:
> > I tested 10 times, it appear 10 times that os can not startup.
> >
> > Steps to Reproduce:
> > 1. vhd-util create -n test.vhd -s 20480
> > 2. xm create test.hvm
> > 3. install Windows 2008 R2 Standard Edition 64 ( disk size: 20G, C:\ 15G,
> > D:\ 5G ) 4. can not startup 5. xm des test.vhd 6. tapdisk2 -n
> > vhd:/mnt/img/test.vhd 7. mount -o offset=105906176 -t ntfs
> > /dev/xen/blktap-2/tapdev0 /mnt/vhd 8. ll /mnt/vhd/Windows/System32 | grep
> > ?
> > ?--------- ? ?    ?           ?            ? pnpts.dll
> > ?--------- ? ?    ?           ?            ? pnpui.dll
> > ?--------- ? ?    ?           ?            ? PnPUnattend.exe
> > ?--------- ? ?    ?           ?            ? PnPutil.exe
> >
> > Additional info:
> > I install
> > Windows 2003 Standard Edition SP1 32(disk size: 50G, C:\50G) on vhd file,
> > the problem disappear.
> > Redhat 5.4 AS 64(disk size:60G, /: 50G, swap: 10G) on vhd file, the
> > problem disappear.
> > Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 100G) on vhd
> > file, the problem disappear.
> > Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 90G, D:\10G) on
> > vhd file, the problem disappear.
> > Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
> > raw file, the problem disappear.
> > Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
> > vhd file, the problem appear.
> > Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 15G, D:\85G) on
> > vhd file, the problem appear.
> >
> > ps:
> > windows 2003 need 3G disk space.
> > redhat 5.4 need 4G disk space.
> > windows 2008 need 8G disk space.
> > the problem disappear means that os can startup and no data error.
> >
> > compile env and filesystem :
> >  Redhat AS 5.4
> >
> > xm info:
> > host                   : vm01
> > release                : 2.6.31.13
> > version                : #1 SMP Wed Apr 21 12:30:21 CST 2010
> > machine                : x86_64
> > nr_cpus                : 16
> > nr_nodes               : 1
> > cores_per_socket       : 4
> > threads_per_core       : 2
> > cpu_mhz                : 2400
> > hw_caps                :
> > bfebfbff:28100800:00000000:00001b40:009ce3bd:00000000:00000001:00000000
> > virt_caps              : hvm
> > total_memory           : 24539
> > free_memory            : 1668
> > node_to_cpu            : node0:0-15
> > node_to_memory         : node0:1668
> > node_to_dma32_mem      : node0:82
> > max_node_id            : 0
> > xen_major              : 4
> > xen_minor              : 0
> > xen_extra              : .0
> > xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> > hvm-3.0-x86_32p hvm-3.0-x86_64
> > xen_scheduler          : credit
> > xen_pagesize           : 4096
> > platform_params        : virt_start=0xffff800000000000
> > xen_changeset          : unavailable
> > xen_commandline        : dom0_max_vcpus=2 dom0_vcpus_pin
> > cc_compiler            : gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
> > cc_compile_by          : root
> > cc_compile_domain      : dev.sd.test.com
> > cc_compile_date        : Mon Apr 26 10:17:37 CST 2010
> > xend_config_format     : 4
> >
>

[-- Attachment #1.2: Type: text/html, Size: 9330 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: VHD BUG in xen4.0 when install windows2008

[yingbin wang]

[-- Attachment #1.1: Type: text/plain, Size: 6508 bytes --]

I have try xenlinux 2.6.18.8. the problem also appear. os can not startup.

Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G)
on vhdfile, the problem
appear.
does anyone successfully install Windows 2008 R2 Standard Edition 64(disk
size: 20G, C:\ 15G, D:\ 5G) on vhd file??
env : (xen4.0, kernel2.6.31.13) or (xen4.0, kernel2.6.18.8)

Cheers,
wyb
在 2010年5月8日 下午8:46，yingbin wang <yingbin.wangyb@gmail.com>写道：

> thank you for your reply.
>
> as you guest, dom0 kernel: pvops 2.6.31.13
>
> I try what you say.
> menu.lst:
> title Xen 4.0 kernel 2.6.31.13
>         root (hd0,0)
>         kernel /xen.gz dom0_mem=4096M dom0_max_vcpus=1 dom0_vcpus_pin
>         module /vmlinuz-2.6.31.13 ro root=LABEL=/ nomodeset
>         module /initrd-2.6.31.13.img
>
> but the problem also appear, os can't startup.
>  Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
> vhd file, the problem appear.
>
> when I install windows 2008, I meet another problem :
> the dom0 hang up, I reboot the physical machine and found some info from
> /var/log/message:
>
> May  8 20:02:47 SS01 tapdisk2[21997]: Assertion 'list_empty(&vreq->next)' failed, line 1822, file tapdisk-vbd.c
>
> May  8 20:02:47 SS01 kernel: tapdisk2[21997]: segfault at 0 ip 000000000040a24f sp 00007fff162b2d90 error 6 in tapdisk2[400000+39000]
>
> May  8 20:02:47 SS01 kernel: blktap_device_fail_pending_requests: 252:2: failing pending write of 11 pages
>
> May  8 20:02:47 SS01 kernel: end_request: I/O error, dev tapdevc, sector 10485752
>
> May  8 20:02:47 SS01 kernel: Buffer I/O error on device tapdevc, logical block 1310719
> May  8 20:02:47 SS01 kernel: lost page write due to I/O error on tapdevc
>
> May  8 20:02:47 SS01 kernel: Buffer I/O error on device tapdevc, logical block 1310720
> May  8 20:02:47 SS01 kernel: lost page write due to I/O error on tapdevc
>
> May  8 20:02:47 SS01 kernel: Buffer I/O error on device tapdevc, logical block 1310721
> May  8 20:02:47 SS01 kernel: lost page write due to I/O error on tapdevc
>
> I don't know the relation between two problems.I hope it give you more
> info to help me solve the problem.
> I think it may be a bug of the pvops 2.6.31.13. I hope there is a way to
> solve it. could you give some advise?
> I will try xenlinux 2.6.18.8 and report the result.
>
> Cheers,
> wyb
> 2010/5/8 Ian Pratt <Ian.Pratt@eu.citrix.com>
>
>  > Description of problem:
>> > after install Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\
>> 15G,
>> > D:\ 5G) on vhd file (as base image), os can not startup.
>>
>> Which dom0 kernel is this with? I'm guessing one of Jeremy's pvops trees?
>>
>> It might be worth reducing the number of dom0 VCPUs to 1 and repeating the
>> experiment to see if that makes a difference.
>>
>> Thanks,
>> Ian
>>
>>
>> > I found data error in C:\Windows\System32 :
>> > ?--------- ? ?    ?           ?            ? pnpts.dll
>> > ?--------- ? ?    ?           ?            ? pnpui.dll
>> > ?--------- ? ?    ?           ?            ? PnPUnattend.exe
>> > ?--------- ? ?    ?           ?            ? PnPutil.exe
>> >
>> > How reproducible:
>> > I tested 10 times, it appear 10 times that os can not startup.
>> >
>> > Steps to Reproduce:
>> > 1. vhd-util create -n test.vhd -s 20480
>> > 2. xm create test.hvm
>> > 3. install Windows 2008 R2 Standard Edition 64 ( disk size: 20G, C:\
>> 15G,
>> > D:\ 5G ) 4. can not startup 5. xm des test.vhd 6. tapdisk2 -n
>> > vhd:/mnt/img/test.vhd 7. mount -o offset=105906176 -t ntfs
>> > /dev/xen/blktap-2/tapdev0 /mnt/vhd 8. ll /mnt/vhd/Windows/System32 |
>> grep
>> > ?
>> > ?--------- ? ?    ?           ?            ? pnpts.dll
>> > ?--------- ? ?    ?           ?            ? pnpui.dll
>> > ?--------- ? ?    ?           ?            ? PnPUnattend.exe
>> > ?--------- ? ?    ?           ?            ? PnPutil.exe
>> >
>> > Additional info:
>> > I install
>> > Windows 2003 Standard Edition SP1 32(disk size: 50G, C:\50G) on vhd
>> file,
>> > the problem disappear.
>> > Redhat 5.4 AS 64(disk size:60G, /: 50G, swap: 10G) on vhd file, the
>> > problem disappear.
>> > Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 100G) on vhd
>> > file, the problem disappear.
>> > Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 90G, D:\10G) on
>> > vhd file, the problem disappear.
>> > Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
>> > raw file, the problem disappear.
>> > Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
>> > vhd file, the problem appear.
>> > Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 15G, D:\85G) on
>> > vhd file, the problem appear.
>> >
>> > ps:
>> > windows 2003 need 3G disk space.
>> > redhat 5.4 need 4G disk space.
>> > windows 2008 need 8G disk space.
>> > the problem disappear means that os can startup and no data error.
>> >
>> > compile env and filesystem :
>> >  Redhat AS 5.4
>> >
>> > xm info:
>> > host                   : vm01
>> > release                : 2.6.31.13
>> > version                : #1 SMP Wed Apr 21 12:30:21 CST 2010
>> > machine                : x86_64
>> > nr_cpus                : 16
>> > nr_nodes               : 1
>> > cores_per_socket       : 4
>> > threads_per_core       : 2
>> > cpu_mhz                : 2400
>> > hw_caps                :
>> > bfebfbff:28100800:00000000:00001b40:009ce3bd:00000000:00000001:00000000
>> > virt_caps              : hvm
>> > total_memory           : 24539
>> > free_memory            : 1668
>> > node_to_cpu            : node0:0-15
>> > node_to_memory         : node0:1668
>> > node_to_dma32_mem      : node0:82
>> > max_node_id            : 0
>> > xen_major              : 4
>> > xen_minor              : 0
>> > xen_extra              : .0
>> > xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
>> > hvm-3.0-x86_32p hvm-3.0-x86_64
>> > xen_scheduler          : credit
>> > xen_pagesize           : 4096
>> > platform_params        : virt_start=0xffff800000000000
>> > xen_changeset          : unavailable
>> > xen_commandline        : dom0_max_vcpus=2 dom0_vcpus_pin
>> > cc_compiler            : gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
>> > cc_compile_by          : root
>> > cc_compile_domain      : dev.sd.test.com
>> > cc_compile_date        : Mon Apr 26 10:17:37 CST 2010
>> > xend_config_format     : 4
>> >
>>
>
>

[-- Attachment #1.2: Type: text/html, Size: 10204 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: VHD BUG in xen4.0 when install windows2008

[Pasi Kärkkäinen]

On Sun, May 09, 2010 at 01:02:42AM +0800, yingbin wang wrote:
>    I have try xenlinux 2.6.18.8. the problem also appear. os can not startup.
> 
>    Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
>    vhd file, the problem appear.
>    does anyone successfully install Windows 2008 R2 Standard Edition 64(disk
>    size: 20G, C:\ 15G, D:\ 5G) on vhd file??
>    env : (xen4.0, kernel2.6.31.13) or (xen4.0, kernel2.6.18.8)
> 

Looking at the log (below) it seems the 'tapdisk2' process segfaults (crashes).
Sounds like a bug in it..

-- Pasi

>    Cheers,
>    wyb
>    ÔÚ 2010Äê5ÔÂ8ÈÕ ÏÂÎç8:46£¬yingbin wang <[1]yingbin.wangyb@gmail.com>ÐŽµÀ£º
> 
>      thank you for your reply.
> 
>      as you guest, dom0 kernel: pvops 2.6.31.13
> 
>      I try what you say.
>      menu.lst:
>      title Xen 4.0 kernel 2.6.31.13
>              root (hd0,0)
>              kernel /xen.gz dom0_mem=4096M dom0_max_vcpus=1 dom0_vcpus_pin
>              module /vmlinuz-2.6.31.13 ro root=LABEL=/ nomodeset
>              module /initrd-2.6.31.13.img
> 
>      but the problem also appear, os can't startup.
>      Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
>      vhd file, the problem appear.
> 
>      when I install windows 2008, I meet another problem :
>      the dom0 hang up, I reboot the physical machine and found some info from
>      /var/log/message:
>      May  8 20:02:47 SS01 tapdisk2[21997]: Assertion 'list_empty(&vreq->next)' failed, line 1822, file tapdisk-vbd.c
>      May  8 20:02:47 SS01 kernel: tapdisk2[21997]: segfault at 0 ip 000000000040a24f sp 00007fff162b2d90 error 6 in tapdisk2[400000+39000]
>      May  8 20:02:47 SS01 kernel: blktap_device_fail_pending_requests: 252:2: failing pending write of 11 pages
>      May  8 20:02:47 SS01 kernel: end_request: I/O error, dev tapdevc, sector 10485752
>      May  8 20:02:47 SS01 kernel: Buffer I/O error on device tapdevc, logical block 1310719
>      May  8 20:02:47 SS01 kernel: lost page write due to I/O error on tapdevc
>      May  8 20:02:47 SS01 kernel: Buffer I/O error on device tapdevc, logical block 1310720
>      May  8 20:02:47 SS01 kernel: lost page write due to I/O error on tapdevc
>      May  8 20:02:47 SS01 kernel: Buffer I/O error on device tapdevc, logical block 1310721
>      May  8 20:02:47 SS01 kernel: lost page write due to I/O error on tapdevc
> 
>      I don't know the relation between two problems.I hope it give you more
>      info to help me solve the problem.
>      I think it may be a bug of the pvops 2.6.31.13. I hope there is a way to
>      solve it. could you give some advise?
>      I will try xenlinux 2.6.18.8 and report the result.
> 
>      Cheers,
>      wyb
>      2010/5/8 Ian Pratt <[2]Ian.Pratt@eu.citrix.com>
> 
>        > Description of problem:
>        > after install Windows 2008 R2 Standard Edition 64(disk size: 20G,
>        C:\ 15G,
>        > D:\ 5G) on vhd file (as base image), os can not startup.
> 
>        Which dom0 kernel is this with? I'm guessing one of Jeremy's pvops
>        trees?
> 
>        It might be worth reducing the number of dom0 VCPUs to 1 and repeating
>        the experiment to see if that makes a difference.
> 
>        Thanks,
>        Ian
> 
>        > I found data error in C:\Windows\System32 :
>        > ?--------- ? ?    ?           ?            ? pnpts.dll
>        > ?--------- ? ?    ?           ?            ? pnpui.dll
>        > ?--------- ? ?    ?           ?            ? PnPUnattend.exe
>        > ?--------- ? ?    ?           ?            ? PnPutil.exe
>        >
>        > How reproducible:
>        > I tested 10 times, it appear 10 times that os can not startup.
>        >
>        > Steps to Reproduce:
>        > 1. vhd-util create -n test.vhd -s 20480
>        > 2. xm create test.hvm
>        > 3. install Windows 2008 R2 Standard Edition 64 ( disk size: 20G, C:\
>        15G,
>        > D:\ 5G ) 4. can not startup 5. xm des test.vhd 6. tapdisk2 -n
>        > vhd:/mnt/img/test.vhd 7. mount -o offset=105906176 -t ntfs
>        > /dev/xen/blktap-2/tapdev0 /mnt/vhd 8. ll /mnt/vhd/Windows/System32 |
>        grep
>        > ?
>        > ?--------- ? ?    ?           ?            ? pnpts.dll
>        > ?--------- ? ?    ?           ?            ? pnpui.dll
>        > ?--------- ? ?    ?           ?            ? PnPUnattend.exe
>        > ?--------- ? ?    ?           ?            ? PnPutil.exe
>        >
>        > Additional info:
>        > I install
>        > Windows 2003 Standard Edition SP1 32(disk size: 50G, C:\50G) on vhd
>        file,
>        > the problem disappear.
>        > Redhat 5.4 AS 64(disk size:60G, /: 50G, swap: 10G) on vhd file, the
>        > problem disappear.
>        > Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 100G) on
>        vhd
>        > file, the problem disappear.
>        > Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 90G,
>        D:\10G) on
>        > vhd file, the problem disappear.
>        > Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G)
>        on
>        > raw file, the problem disappear.
>        > Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G)
>        on
>        > vhd file, the problem appear.
>        > Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 15G,
>        D:\85G) on
>        > vhd file, the problem appear.
>        >
>        > ps:
>        > windows 2003 need 3G disk space.
>        > redhat 5.4 need 4G disk space.
>        > windows 2008 need 8G disk space.
>        > the problem disappear means that os can startup and no data error.
>        >
>        > compile env and filesystem :
>        >  Redhat AS 5.4
>        >
>        > xm info:
>        > host                   : vm01
>        > release                : 2.6.31.13
>        > version                : #1 SMP Wed Apr 21 12:30:21 CST 2010
>        > machine                : x86_64
>        > nr_cpus                : 16
>        > nr_nodes               : 1
>        > cores_per_socket       : 4
>        > threads_per_core       : 2
>        > cpu_mhz                : 2400
>        > hw_caps                :
>        >
>        bfebfbff:28100800:00000000:00001b40:009ce3bd:00000000:00000001:00000000
>        > virt_caps              : hvm
>        > total_memory           : 24539
>        > free_memory            : 1668
>        > node_to_cpu            : node0:0-15
>        > node_to_memory         : node0:1668
>        > node_to_dma32_mem      : node0:82
>        > max_node_id            : 0
>        > xen_major              : 4
>        > xen_minor              : 0
>        > xen_extra              : .0
>        > xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p
>        hvm-3.0-x86_32
>        > hvm-3.0-x86_32p hvm-3.0-x86_64
>        > xen_scheduler          : credit
>        > xen_pagesize           : 4096
>        > platform_params        : virt_start=0xffff800000000000
>        > xen_changeset          : unavailable
>        > xen_commandline        : dom0_max_vcpus=2 dom0_vcpus_pin
>        > cc_compiler            : gcc version 4.1.2 20080704 (Red Hat
>        4.1.2-46)
>        > cc_compile_by          : root
>        > cc_compile_domain      : [3]dev.sd.test.com
>        > cc_compile_date        : Mon Apr 26 10:17:37 CST 2010
>        > xend_config_format     : 4
>        >
> 
> References
> 
>    Visible links
>    1. mailto:yingbin.wangyb@gmail.com
>    2. mailto:Ian.Pratt@eu.citrix.com
>    3. http://dev.sd.test.com/

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

Re: VHD BUG in xen4.0 when install windows2008

[Daniel Stodden]

On Sat, 2010-05-08 at 15:52 -0400, Pasi Kärkkäinen wrote:
> On Sun, May 09, 2010 at 01:02:42AM +0800, yingbin wang wrote:
> >    I have try xenlinux 2.6.18.8. the problem also appear. os can not startup.
> > 
> >    Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
> >    vhd file, the problem appear.
> >    does anyone successfully install Windows 2008 R2 Standard Edition 64(disk
> >    size: 20G, C:\ 15G, D:\ 5G) on vhd file??
> >    env : (xen4.0, kernel2.6.31.13) or (xen4.0, kernel2.6.18.8)
> > 
> 
> Looking at the log (below) it seems the 'tapdisk2' process segfaults (crashes).
> Sounds like a bug in it..

This is the loop pulling requests from the userspace I/O ring.
Missing a sanity check on the message content, hence the crash.

I would have bet it's smp-related, but sounds as if not.

Daniel

AW: VHD BUG in xen4.0 when install windows2008

[Heiko Wundram]

As I'm seeing a similar behavior of tapdisk2 (see my recent posts to xen-users, especially "blktap2, also broken in current pv_ops stable-2.6.32.x?"), I can confirm that at least in my testing (I've done some more over the weekend, re. that message), this is indeed an "SMP-related" problem, but only for HVM-64bit domains.

What I can basically say is that:

1) Uni/Multi/32-bit/64-bit PV domains run properly.
1) Uni-VCPU, 32-bit HVM domains run properly.
2) Multi-VCPU, 32-bit HVM domains run properly.
3) Uni-VCPU, 64-bit HVM domains run properly.
4) Multi-VCPU, 64-bit HVM domains cause tapdisk2 to segfault, sometimes, under heavy I/O, and if that happens, causes the Dom0-kernel to freeze/lock up, Bug, and/or all other kinds of undefined behavior, where I really haven't made out a pattern yet.

Interestingly, these errors do not happen when using the "normal" blkback-driver, and I'm very positive (at least that's what happened during my testing) that it's specific to Multi-VCPU, 64-bit HVM domains that the crash occurs, independent of the number of VCPUs bound to Dom0.

--- Heiko.


-----Ursprüngliche Nachricht-----
Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] Im Auftrag von Daniel Stodden
Gesendet: Sonntag, 9. Mai 2010 20:41
An: Pasi Kärkkäinen
Cc: Ian Pratt; yingbin wang; xen-devel@lists.xensource.com
Betreff: Re: [Xen-devel] VHD BUG in xen4.0 when install windows2008

On Sat, 2010-05-08 at 15:52 -0400, Pasi Kärkkäinen wrote:
> On Sun, May 09, 2010 at 01:02:42AM +0800, yingbin wang wrote:
> >    I have try xenlinux 2.6.18.8. the problem also appear. os can not startup.
> > 
> >    Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
> >    vhd file, the problem appear.
> >    does anyone successfully install Windows 2008 R2 Standard Edition 64(disk
> >    size: 20G, C:\ 15G, D:\ 5G) on vhd file??
> >    env : (xen4.0, kernel2.6.31.13) or (xen4.0, kernel2.6.18.8)
> > 
> 
> Looking at the log (below) it seems the 'tapdisk2' process segfaults (crashes).
> Sounds like a bug in it..

This is the loop pulling requests from the userspace I/O ring.
Missing a sanity check on the message content, hence the crash.

I would have bet it's smp-related, but sounds as if not.

Daniel


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

Re: AW: VHD BUG in xen4.0 when install windows2008

[Daniel Stodden]

On Sun, 2010-05-09 at 15:03 -0400, Heiko Wundram wrote:
> As I'm seeing a similar behavior of tapdisk2 (see my recent posts to xen-users, especially "blktap2, also broken in current pv_ops stable-2.6.32.x?"), I can confirm that at least in my testing (I've done some more over the weekend, re. that message), this is indeed an "SMP-related" problem, but only for HVM-64bit domains.
> 
> What I can basically say is that:
> 
> 1) Uni/Multi/32-bit/64-bit PV domains run properly.
> 1) Uni-VCPU, 32-bit HVM domains run properly.
> 2) Multi-VCPU, 32-bit HVM domains run properly.
> 3) Uni-VCPU, 64-bit HVM domains run properly.
> 4) Multi-VCPU, 64-bit HVM domains cause tapdisk2 to segfault, sometimes, under heavy I/O, and if that happens, causes the Dom0-kernel to freeze/lock up, Bug, and/or all other kinds of undefined behavior, where I really haven't made out a pattern yet.
> 
> Interestingly, these errors do not happen when using the "normal" blkback-driver, and I'm very positive (at least that's what happened during my testing) that it's specific to Multi-VCPU, 64-bit HVM domains that the crash occurs, independent of the number of VCPUs bound to Dom0.

Okay, one thing which was going to happen soon is a patch to make
tapdisk run the device queue synchronously. From your description I'm
just not very convinced that this resolves such issues as well. Looks
like it needs some 64 bit testing beforehand.

Thanks for the hints. Does HVM up there mean it's rather triggered by
qemu alone? Were you running pv drivers?

Cheers,
Daniel

AW: AW: VHD BUG in xen4.0 when install windows2008

[Heiko Wundram]

The 64-bit HVM domain I've tested was a Windows (2008 R2 Web Server) domain, without PV drivers, so yeah, it was triggered by qemu alone in my specific test case.

Looking back at my testing, I'm not 100% certain that the bug doesn't occur on 64-bit Multi-VCPU PV-domains (I thought I tested those "properly", but I just did one test case with Ubuntu 10.04 running "fully" PV, and after the system booted successfully, I didn't test whether bonnie++-I/O or any such would trigger the behavior; installation was done in a Dom0 chroot anyway for that, so I can't actually say whether there'd also be a bug here), but I'm positive that Multi-VCPU 32-bit HVM and PV domains do not exhibit the errant behavior, just as Uni-VCPU 64-bit HVM and PV domains don't.

If you have a patch to test (regarding the synchronous queuing of tapdisk2), I'd be happy to give it a shot with my specific setup.

--- Heiko.

PS: again, sorry for topposting; I currently don't have access to a "functioning" email client... Which begs the question: anybody know of a way to make Outlook behave sanely concerning quoting of mails? ;-)

-----Ursprüngliche Nachricht-----
Von: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] Im Auftrag von Daniel Stodden
Gesendet: Montag, 10. Mai 2010 09:49
An: Heiko Wundram
Cc: xen-devel@lists.xensource.com
Betreff: Re: AW: [Xen-devel] VHD BUG in xen4.0 when install windows2008

On Sun, 2010-05-09 at 15:03 -0400, Heiko Wundram wrote:
> As I'm seeing a similar behavior of tapdisk2 (see my recent posts to xen-users, especially "blktap2, also broken in current pv_ops stable-2.6.32.x?"), I can confirm that at least in my testing (I've done some more over the weekend, re. that message), this is indeed an "SMP-related" problem, but only for HVM-64bit domains.
> 
> What I can basically say is that:
> 
> 1) Uni/Multi/32-bit/64-bit PV domains run properly.
> 1) Uni-VCPU, 32-bit HVM domains run properly.
> 2) Multi-VCPU, 32-bit HVM domains run properly.
> 3) Uni-VCPU, 64-bit HVM domains run properly.
> 4) Multi-VCPU, 64-bit HVM domains cause tapdisk2 to segfault, sometimes, under heavy I/O, and if that happens, causes the Dom0-kernel to freeze/lock up, Bug, and/or all other kinds of undefined behavior, where I really haven't made out a pattern yet.
> 
> Interestingly, these errors do not happen when using the "normal" blkback-driver, and I'm very positive (at least that's what happened during my testing) that it's specific to Multi-VCPU, 64-bit HVM domains that the crash occurs, independent of the number of VCPUs bound to Dom0.

Okay, one thing which was going to happen soon is a patch to make
tapdisk run the device queue synchronously. From your description I'm
just not very convinced that this resolves such issues as well. Looks
like it needs some 64 bit testing beforehand.

Thanks for the hints. Does HVM up there mean it's rather triggered by
qemu alone? Were you running pv drivers?

Cheers,
Daniel


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

Re: AW: AW: VHD BUG in xen4.0 when install windows2008

[Daniel Stodden]

On Mon, 2010-05-10 at 04:17 -0400, Heiko Wundram wrote:
> The 64-bit HVM domain I've tested was a Windows (2008 R2 Web Server) domain, without PV drivers, so yeah, it was triggered by qemu alone in my specific test case.
> 
> Looking back at my testing, I'm not 100% certain that the bug doesn't occur on 64-bit Multi-VCPU PV-domains (I thought I tested those "properly", but I just did one test case with Ubuntu 10.04 running "fully" PV, and after the system booted successfully, I didn't test whether bonnie++-I/O or any such would trigger the behavior; installation was done in a Dom0 chroot anyway for that, so I can't actually say whether there'd also be a bug here), but I'm positive that Multi-VCPU 32-bit HVM and PV domains do not exhibit the errant behavior, just as Uni-VCPU 64-bit HVM and PV domains don't.

Thanks. I'm mainly looking for the cheapest way to come across a repro.

> If you have a patch to test (regarding the synchronous queuing of tapdisk2), I'd be happy to give it a shot with my specific setup.

I'll cc you when posting them. Any additional testing before Jeremy gets
to pick them up is welcome.

> --- Heiko.
> 
> PS: again, sorry for topposting; I currently don't have access to a "functioning" email client... 
> Which begs the question: anybody know of a way to make Outlook behave sanely concerning quoting of mails? ;-)

I gave up on Outlook for basically that reason. 
But I don't think people mind.

Daniel

Re: AW: VHD BUG in xen4.0 when install windows2008

[yingbin wang]

hi,
had you created the patch to make tapdisk run the device queue synchronously?
if yes, could you tell me how to get it?

thanks
wyb

2010/5/10 Daniel Stodden <daniel.stodden@citrix.com>:
> On Sun, 2010-05-09 at 15:03 -0400, Heiko Wundram wrote:
>> As I'm seeing a similar behavior of tapdisk2 (see my recent posts to xen-users, especially "blktap2, also broken in current pv_ops stable-2.6.32.x?"), I can confirm that at least in my testing (I've done some more over the weekend, re. that message), this is indeed an "SMP-related" problem, but only for HVM-64bit domains.
>>
>> What I can basically say is that:
>>
>> 1) Uni/Multi/32-bit/64-bit PV domains run properly.
>> 1) Uni-VCPU, 32-bit HVM domains run properly.
>> 2) Multi-VCPU, 32-bit HVM domains run properly.
>> 3) Uni-VCPU, 64-bit HVM domains run properly.
>> 4) Multi-VCPU, 64-bit HVM domains cause tapdisk2 to segfault, sometimes, under heavy I/O, and if that happens, causes the Dom0-kernel to freeze/lock up, Bug, and/or all other kinds of undefined behavior, where I really haven't made out a pattern yet.
>>
>> Interestingly, these errors do not happen when using the "normal" blkback-driver, and I'm very positive (at least that's what happened during my testing) that it's specific to Multi-VCPU, 64-bit HVM domains that the crash occurs, independent of the number of VCPUs bound to Dom0.
>
> Okay, one thing which was going to happen soon is a patch to make
> tapdisk run the device queue synchronously. From your description I'm
> just not very convinced that this resolves such issues as well. Looks
> like it needs some 64 bit testing beforehand.
>
> Thanks for the hints. Does HVM up there mean it's rather triggered by
> qemu alone? Were you running pv drivers?
>
> Cheers,
> Daniel
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: AW: VHD BUG in xen4.0 when install windows2008

[Daniel Stodden]

On Sat, 2010-06-12 at 01:04 -0400, yingbin wang wrote:
> hi,
> had you created the patch to make tapdisk run the device queue synchronously?
> if yes, could you tell me how to get it?

Right. These were landed. Present xen-unstable.hg should be not as
unstable as it says it is.

Can you or Heiko build that and see if anything improved? I'm a bit
short on time right now.

If that doesn't work for you, I'll look into it myself.

Daniel

Re: AW: VHD BUG in xen4.0 when install windows2008

[yingbin wang]

could you give me the exact changlog about the patch?

2010/6/12 Daniel Stodden <daniel.stodden@citrix.com>:
> On Sat, 2010-06-12 at 01:04 -0400, yingbin wang wrote:
>> hi,
>> had you created the patch to make tapdisk run the device queue synchronously?
>> if yes, could you tell me how to get it?
>
> Right. These were landed. Present xen-unstable.hg should be not as
> unstable as it says it is.
>
> Can you or Heiko build that and see if anything improved? I'm a bit
> short on time right now.
>
> If that doesn't work for you, I'll look into it myself.
>
> Daniel
>
>

Re: AW: VHD BUG in xen4.0 when install windows2008

[Daniel Stodden]

On Sat, 2010-06-12 at 06:47 -0400, yingbin wang wrote:
> could you give me the exact changlog about the patch?

You want to get to the tip of these:

http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=shortlog;h=refs/heads/xen/dom0/backend/blktap2

Which ones you're missing depends on what kernel you already got.
What are you running?

Daniel

Re: AW: VHD BUG in xen4.0 when install windows2008

[yingbin wang]

I know what you mean. now I know the patchs are in
/heads/xen/dom0/backend/blktap2.
do I need to get patchs from other places? or only in
/heads/xen/dom0/backend/blktap2?

ps:
you say present xen-unstable.hg should be not as unstable as it says it is.
I don't know there is a head about blktap2 in xen.git before, so it
makes me think the patch is in xen-unstable.hg.

2010/6/13 Daniel Stodden <daniel.stodden@citrix.com>:
> On Sat, 2010-06-12 at 06:47 -0400, yingbin wang wrote:
>> could you give me the exact changlog about the patch?
>
> You want to get to the tip of these:
>
> http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=shortlog;h=refs/heads/xen/dom0/backend/blktap2
>
> Which ones you're missing depends on what kernel you already got.
> What are you running?
>
> Daniel
>
>

Re: AW: VHD BUG in xen4.0 when install windows2008

[Daniel Stodden]

On Sat, 2010-06-12 at 23:01 -0400, yingbin wang wrote:
> I know what you mean. now I know the patchs are in
> /heads/xen/dom0/backend/blktap2.
> do I need to get patchs from other places? or only in
> /heads/xen/dom0/backend/blktap2?

Try those first. *Should* work okay [, but didn't get a lot of testing.]
There are a couple more kernel updates coming, which should further
improve interfacing with older installations.

> ps:
> you say present xen-unstable.hg should be not as unstable as it says it is.
> I don't know there is a head about blktap2 in xen.git before, so it
> makes me think the patch is in xen-unstable.hg.

No, the changes you were after are only in the kernel. The userspace
part, including tapdisk, didn't change much since then.

Daniel

Re: VHD BUG in xen4.0 when install windows2008

[yingbin wang]

[-- Attachment #1.1: Type: text/plain, Size: 4797 bytes --]

the install problem is solved.

after install Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G,
D:\ 5G) on vhd file (as base image), os reboot.
I use command( ps aux | grep tapdisk2 ) to see the status and found that
after new tapdisk2 process create, old tapdisk2 process didn't close.
I found something from xend source. when xend destroy tap2 device, xend
create a thread to write remove to /sys/class/blktap2/blktap0/remove and
then continue to create new tap2 device, but old tapdisk2 process
didn't immediately close.

so I add some code before xend exec cmd ( [ TAPDISK_BINARY, '-n', '%s:%s' %
(params, file) ] ). it just wait old tapdisk2 process. when it know the old
process is closed, it will create new tapdisk2 process.

after update
/usr/lib64/python2.4/site-packages/xen/xend/server/BlktapController.py and
restart xend, I install Windows 2008 R2 Standard Edition 64(disk size: 20G,
C:\ 15G, D:\ 5G) on vhd file (as base image). the problem disappear. I
tested 5 times, the problem didn't appear. I will do more test case later.

the attachment is the new code of BlktapController.py ( base on xen 4.0 ).
you can copy it to /usr/lib64/python2.4/site-packages/xen/xend/server/ and
 restart xend.

this is a tentative plan, I will track the real reason later.

Cheers,
wyb

2010/5/8 yingbin wang <yingbin.wangyb@gmail.com>

> Description of problem:
> after install Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G,
> D:\ 5G) on vhd file (as base image), os can not startup.
> I found data error in C:\Windows\System32 :
> ?--------- ? ?    ?           ?            ? pnpts.dll
> ?--------- ? ?    ?           ?            ? pnpui.dll
> ?--------- ? ?    ?           ?            ? PnPUnattend.exe
> ?--------- ? ?    ?           ?            ? PnPutil.exe
>
> How reproducible:
> I tested 10 times, it appear 10 times that os can not startup.
>
> Steps to Reproduce:
> 1. vhd-util create -n test.vhd -s 20480
> 2. xm create test.hvm
> 3. install Windows 2008 R2 Standard Edition 64 ( disk size: 20G, C:\ 15G,
> D:\ 5G )
> 4. can not startup
> 5. xm des test.vhd
> 6. tapdisk2 -n vhd:/mnt/img/test.vhd
> 7. mount -o offset=105906176 -t ntfs /dev/xen/blktap-2/tapdev0 /mnt/vhd
> 8. ll /mnt/vhd/Windows/System32 | grep ?
> ?--------- ? ?    ?           ?            ? pnpts.dll
> ?--------- ? ?    ?           ?            ? pnpui.dll
> ?--------- ? ?    ?           ?            ? PnPUnattend.exe
> ?--------- ? ?    ?           ?            ? PnPutil.exe
>
> Additional info:
> I install
> Windows 2003 Standard Edition SP1 32(disk size: 50G, C:\50G) on vhd file,
> the problem disappear.
> Redhat 5.4 AS 64(disk size:60G, /: 50G, swap: 10G) on vhd file, the
> problem disappear.
> Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 100G) on vhdfile, the problem
> disappear.
> Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 90G, D:\10G) on
> vhd file, the problem disappear.
> Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on
> raw file, the problem disappear.
> Windows 2008 R2 Standard Edition 64(disk size: 20G, C:\ 15G, D:\ 5G) on vhd
> file, the problem appear.
> Windows 2008 R2 Standard Edition 64(disk size: 100G, C:\ 15G, D:\85G) on
> vhd file, the problem appear.
>
> ps:
> windows 2003 need 3G disk space.
> redhat 5.4 need 4G disk space.
> windows 2008 need 8G disk space.
> the problem disappear means that os can startup and no data error.
>
> compile env and filesystem :
>  Redhat AS 5.4
>
> xm info:
> host                   : vm01
> release                : 2.6.31.13
> version                : #1 SMP Wed Apr 21 12:30:21 CST 2010
> machine                : x86_64
> nr_cpus                : 16
> nr_nodes               : 1
> cores_per_socket       : 4
> threads_per_core       : 2
> cpu_mhz                : 2400
> hw_caps                :
> bfebfbff:28100800:00000000:00001b40:009ce3bd:00000000:00000001:00000000
> virt_caps              : hvm
> total_memory           : 24539
> free_memory            : 1668
> node_to_cpu            : node0:0-15
> node_to_memory         : node0:1668
> node_to_dma32_mem      : node0:82
> max_node_id            : 0
> xen_major              : 4
> xen_minor              : 0
> xen_extra              : .0
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xffff800000000000
> xen_changeset          : unavailable
> xen_commandline        : dom0_max_vcpus=2 dom0_vcpus_pin
> cc_compiler            : gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)
> cc_compile_by          : root
> cc_compile_domain      : dev.sd.test.com
> cc_compile_date        : Mon Apr 26 10:17:37 CST 2010
> xend_config_format     : 4
>
>

[-- Attachment #1.2: Type: text/html, Size: 8744 bytes --]

[-- Attachment #2: BlktapController.py --]
[-- Type: application/octet-stream, Size: 9618 bytes --]

# Copyright (c) 2005, XenSource Ltd.
import string, re
import time
import logging
import os

from xen.xend.server.blkif import BlkifController
from xen.xend.XendLogging import log
from xen.util.xpopen import xPopen3

phantomDev = 0;
phantomId = 0;

TAPDISK_SYSFS   = '/sys/class/blktap2'
TAPDISK_BINARY  = '/usr/sbin/tapdisk2'
TAPDISK_DEVICE  = '/dev/xen/blktap-2/tapdev'
TAPDISK_CONTROL = TAPDISK_SYSFS + '/blktap'

blktap1_disk_types = [
    'aio',
    'sync',
    'vmdk',
    'ram',
    'qcow',
    'qcow2',
    'ioemu',
    ]

blktap2_disk_types = [
    'aio',
    'ram',
    'qcow',
    'vhd',
    'remus',
    ]

blktap_disk_types = blktap1_disk_types + blktap2_disk_types

def doexec(args, inputtext=None):
    """Execute a subprocess, then return its return code, stdout and stderr"""
    proc = xPopen3(args, True)
    if inputtext != None:
        proc.tochild.write(inputtext)
    stdout = proc.fromchild
    stderr = proc.childerr
    rc = proc.wait()
    return (rc,stdout,stderr)

def parseDeviceString(device):
    if device.find('/dev') == -1:
        raise Exception, 'invalid tap device: ' + device

    pattern = re.compile(TAPDISK_DEVICE + '(\d+)$')
    groups  = pattern.search(device)
    if not groups:
        raise Exception, 'malformed tap device: ' + device

    minor   = groups.group(1)
    control = TAPDISK_CONTROL + minor

    return minor, device, control

# blktap1 device controller
class BlktapController(BlkifController):
    def __init__(self, vm):
        BlkifController.__init__(self, vm)
        
    def frontendRoot(self):
        """@see DevController#frontendRoot"""
        
        return "%s/device/vbd" % self.vm.getDomainPath()

    def getDeviceDetails(self, config):
        (devid, back, front) = BlkifController.getDeviceDetails(self, config)

        phantomDevid = 0
        wrapped = False

        try:
            imagetype = self.vm.info['image']['type']
        except:
            imagetype = ""

        if imagetype == 'hvm':
            tdevname = back['dev']
            index = ['c', 'd', 'e', 'f', 'g', 'h', 'i', \
                     'j', 'l', 'm', 'n', 'o', 'p']
            while True:
                global phantomDev
                global phantomId
                import os, stat

                phantomId = phantomId + 1
                if phantomId == 16:
                    if index[phantomDev] == index[-1]:
                        if wrapped:
                            raise VmError(" No loopback block \
                                       devices are available. ")
                        wrapped = True
                        phantomDev = 0
                    else:
                        phantomDev = phantomDev + 1
                    phantomId = 1
                devname = 'xvd%s%d' % (index[phantomDev], phantomId)
                try:
                    info = os.stat('/dev/%s' % devname)
                except:
                    break

            vbd = { 'mode': 'w', 'device': devname }
            fn = 'tap:%s' % back['params']

            # recurse ... by creating the vbd, then fallthrough
            # and finish creating the original device

            from xen.xend import XendDomain
            dom0 = XendDomain.instance().privilegedDomain()
            phantomDevid = dom0.create_phantom_vbd_with_vdi(vbd, fn)
            # we need to wait for this device at a higher level
            # the vbd that gets created will have a link to us
            # and will let them do it there

        # add a hook to point to the phantom device,
        # root path is always the same (dom0 tap)
        if phantomDevid != 0:
            front['phantom_vbd'] = '/local/domain/0/backend/tap/0/%s' \
                                   % str(phantomDevid)

        return (devid, back, front)

class Blktap2Controller(BlktapController):
    def __init__(self, vm):
        BlktapController.__init__(self, vm)

    def backendPath(self, backdom, devid):
        if self.deviceClass == 'tap2':
            deviceClass = 'vbd'
        else:
            deviceClass = 'tap'
        return "%s/backend/%s/%s/%d" % (backdom.getDomainPath(),
                                        deviceClass,
                                        self.vm.getDomid(), devid)

    def getDeviceDetails(self, config):

        (devid, back, front) = BlktapController.getDeviceDetails(self, config)
        if self.deviceClass == 'tap2':
        # since blktap2 uses blkback as a backend the 'params' feild contains
        # the path to the blktap2 device (/dev/xen/blktap-2/tapdev*). As well,
        # we need to store the params used to create the blktap2 device
        # (tap:tapdisk:<driver>:/<image-path>)
            tapdisk_uname = config.get('tapdisk_uname', '')
            (_, tapdisk_params) = string.split(tapdisk_uname, ':', 1)
            back['tapdisk-params'] = tapdisk_params 
            
        return (devid, back, front)

    def getDeviceConfiguration(self, devid, transaction = None):

        # this is a blktap2 device, so we need to overwrite the 'params' feild
        # with the actual blktap2 parameters. (the vbd parameters are of little
        # use to us)
        config = BlktapController.getDeviceConfiguration(self, devid, transaction)
        if transaction is None:
            tapdisk_params = self.readBackend(devid, 'tapdisk-params')
        else:
            tapdisk_params = self.readBackendTxn(transaction, devid, 'tapdisk-params')
        if tapdisk_params:
            config['uname'] = 'tap:' + tapdisk_params

        return config


    def createDevice(self, config):

        uname = config.get('uname', '')
        try:
            (typ, subtyp, params, file) = string.split(uname, ':', 3)
            if subtyp not in ('tapdisk', 'ioemu'):
                raise ValueError('invalid subtype')
        except:
            (typ, params, file) = string.split(uname, ':', 2)
            subtyp = 'tapdisk'

        #check for blktap2 installation.
        blktap2_installed=0;
        (rc,stdout, stderr) = doexec("cat /proc/devices");
        out = stdout.read();
        stdout.close();
        stderr.close();
        if( out.find("blktap2") >= 0 ):
            blktap2_installed=1;

        if typ in ('tap'):
            if subtyp in ('tapdisk'):
                if params not in blktap2_disk_types or not blktap2_installed:
                    # pass this device off to BlktapController
                    log.warn('WARNING: using deprecated blktap module')
                    self.deviceClass = 'tap'
                    devid = BlktapController.createDevice(self, config)
                    self.deviceClass = 'tap2'
                    return devid

        if self.vm.image and self.vm.image.memory_sharing:
            cmd = [ TAPDISK_BINARY, '-n', '%s:%s' % (params, file), '-s', '%d' % self.vm.getDomid() ]
        else:
            cmd = [ TAPDISK_BINARY, '-n', '%s:%s' % (params, file) ]

        logging.getLogger("xend.XendDomainInfo").debug("wait tapdisk2 process start");
        # check tapdisk2 process
        logging.getLogger("xend.XendDomainInfo").debug("check tapdisk2 process");
        trycount = 0
        num = 60
        # ps -aux | grep "/usr/sbin/tapdisk2" | grep "/mnt/hchina/test/redhat-5.4-64.vhd"
        check_cmd = 'ps -aux | grep "%s" | grep "%s" | grep -v grep' % (TAPDISK_BINARY, file)
        logging.getLogger("xend.XendDomainInfo").debug("%s",check_cmd);
        while (trycount < num):
            time.sleep(5)
            pipe_ps = os.popen(check_cmd)
            list_tapdisk2 = pipe_ps.readlines()
            pipe_ps.close()
            if len(list_tapdisk2) == 0:
                break
            else:
                trycount = trycount + 1;

        if trycount == num:
            logging.getLogger("xend.XendDomainInfo").debug("wait tapdisk2 process fail");
        logging.getLogger("xend.XendDomainInfo").debug("wait tapdisk2 process end");

        (rc,stdout,stderr) = doexec(cmd)

        if rc != 0:
            err = stderr.read();
            out = stdout.read();
            stdout.close();
            stderr.close();
            raise Exception, 'Failed to create device.\n    stdout: %s\n    stderr: %s\nCheck that target \"%s\" exists and that blktap2 driver installed in dom0.' % (out.rstrip(), err.rstrip(), file);

        minor, device, control = parseDeviceString(stdout.readline())
        stdout.close();
        stderr.close();

        # modify the configutration to create a blkback for the underlying
        # blktap2 device. Note: we need to preserve the original tapdisk uname
        # (it is used during save/restore and for managed domains).
        config.update({'tapdisk_uname' : uname})
        config.update({'uname' : 'phy:' + device.rstrip()})

        devid = BlkifController.createDevice(self, config)
        config.update({'uname' : uname})
        config.pop('tapdisk_uname')
        return devid

    # The new blocktap implementation requires a sysfs signal to close
    # out disks.  This function is called from a thread when the
    # domain is detached from the disk.
    def finishDeviceCleanup(self, backpath, path):
        """Perform any device specific cleanup

        @backpath backend xenstore path.
        @path frontend device path

        """

        #Figure out what we're going to wait on.
        self.waitForBackend_destroy(backpath)

        #Figure out the sysfs path.
        minor, dev, ctrl = parseDeviceString(path)

        #Close out the disk
        f = open(ctrl + '/remove', 'w')
        f.write('remove');
        f.close()

        return


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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