BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Dante Cinco]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

I'm getting this message (subject line) in daemon.log every time I
start or restart xend. I'm not sure if this is related to the fact
that I cannot boot up my Windows domU from a VHD file. The Windows
domU was working fine with Xen 4.0.0 (with 2.6.32.14 dom0 kernel).
When I upgraded to Xen 4.0.1-rc4 (with 2.6.32.16 dom0 kernel), I can
no long boot the Windows domU from VHD. The VNC console for the
Windows HVM has this message:

Booting from Hard Disk ...
Boot from Hard Disk failed; could not read the boot disk

No bootable device.
Powering off in 30 seconds.

Here's the disk setting in my Windows domU config file: disk =
['tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w']

Here's the other BLKTAPCTRL messages in daemon.log:

BLKTAPCTRL[2444]: blktapctrl.c:790: blktapctrl: v1.0.0
BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (aio)]
BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (sync)]
BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [vmware image (vmdk)]
BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [ramdisk image (ram)]
BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow disk (qcow)]
BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)]
BLKTAPCTRL[2444]: blktapctrl_linux.c:86: blktap0 open failed
BLKTAPCTRL[2444]: blktapctrl.c:859: couldn't open blktap interface
BLKTAPCTRL[2444]: blktapctrl.c:922: Unable to start blktapctrl

I've also attached the output from /var/log/xen/xend.log when
attempting to bringup the Windows domU.

When the Windows domU VHD file was booting under Xen 4.0.0, I would
get these messages in syslog:

tapdisk2[4833]: Created /dev/xen/blktap-2/control device
tapdisk2[4833]: Created /dev/xen/blktap-2/blktap0 device
tapdisk2[4833]: Created /dev/xen/blktap-2/tapdev0 device
tapdisk2[4833]: new interface: ring: 253, device: 253, minor: 0
tapdisk2[4833]: I/O queue driver: lio
tapdisk2[4833]: /mnt/win2008sp2.vhd version: tap 0x00010003, b: 12800,
a: 6903, f: 6087, n: 28330016
tapdisk2[4833]: opened image /mnt/win2008sp2.vhd (1 users, state:
0x00000001, type: 4)
tapdisk2[4833]: VBD CHAIN:
tapdisk2[4833]: /mnt/win2008sp2.vhd: 4

I appreciate any insight or recommendation.

Thanks.

- Dante

[-- Attachment #2: xend_win2008sp.log --]
[-- Type: application/octet-stream, Size: 12218 bytes --]

[2010-07-19 14:06:41 2682] DEBUG (XendDomainInfo:101) XendDomainInfo.create(['vm', ['name', 'svm'], ['memory', 1024], ['shadow_memory', 8], ['on_poweroff', 'destroy'], ['on_reboot', 'restart'], ['on_crash', 'destroy'], ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['vcpus', 1], ['cpus', ['15']], ['oos', 1], ['image', ['hvm', ['kernel', '/usr/lib64/xen/boot/hvmloader'], ['videoram', 4], ['serial', 'pty'], ['acpi', 1], ['apic', 1], ['boot', 'c'], ['cpuid', []], ['cpuid_check', []], ['device_model', '/usr/lib64/xen/bin/qemu-dm'], ['fda', ''], ['fdb', ''], ['guest_os_type', 'default'], ['hap', 1], ['hpet', 0], ['isa', 0], ['keymap', ''], ['localtime', 0], ['nographic', 0], ['oos', 1], ['pae', 1], ['pci', []], ['pci_msitranslate', 1], ['pci_power_mgmt', 0], ['rtc_timeoffset', 0], ['sdl', 0], ['soundhw', ''], ['stdvga', 0], ['timer_mode', 1], ['usb', 0], ['usbdevice', 'tablet'], ['vcpus', 1], ['vnc', 1], ['vncconsole', 1], ['vnclisten', '0.0.0.0'], ['vncunused', 1], ['viridian', 0], ['vpt_align', 1], ['xauthority', '/root/.Xauthority'], ['xen_platform_pci', 1], ['memory_sharing', 0], ['vncpasswd', 'XXXXXXXX'], ['tsc_mode', 0], ['nomigrate', 0]]], ['s3_integrity', 1], ['device', ['tap', ['uname', 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd'], ['dev', 'xvda:sda1'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'eth0'], ['model', 'e1000'], ['mac', '00:16:3e:00:20:02']]]])
[2010-07-19 14:06:41 2682] DEBUG (XendDomainInfo:2508) XendDomainInfo.constructDomain
[2010-07-19 14:06:41 2682] DEBUG (balloon:220) Balloon: 11910604 KiB free; need 16384; done.
[2010-07-19 14:06:41 2682] DEBUG (XendDomain:464) Adding Domain: 1
[2010-07-19 14:06:41 2682] DEBUG (XendDomainInfo:2818) XendDomainInfo.initDomain: 1 256
[2010-07-19 14:06:41 2682] DEBUG (image:339) No VNC passwd configured for vfb access
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: boot, val: c
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: fda, val: None
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: fdb, val: None
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: soundhw, val: None
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: localtime, val: 0
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: serial, val: ['pty']
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: std-vga, val: 0
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: isa, val: 0
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: acpi, val: 1
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: usb, val: 0
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: usbdevice, val: tablet
[2010-07-19 14:06:41 2682] DEBUG (image:891) args: gfx_passthru, val: None
[2010-07-19 14:06:41 2682] INFO (image:822) Need to create platform device.[domid:1]
[2010-07-19 14:06:41 2682] DEBUG (XendDomainInfo:2845) _initDomain:shadow_memory=0x8, memory_static_max=0x40000000, memory_static_min=0x0.
[2010-07-19 14:06:41 2682] INFO (image:182) buildDomain os=hvm dom=1 vcpus=1
[2010-07-19 14:06:41 2682] DEBUG (image:949) domid          = 1
[2010-07-19 14:06:41 2682] DEBUG (image:950) image          = /usr/lib64/xen/boot/hvmloader
[2010-07-19 14:06:41 2682] DEBUG (image:951) store_evtchn   = 2
[2010-07-19 14:06:41 2682] DEBUG (image:952) memsize        = 1024
[2010-07-19 14:06:41 2682] DEBUG (image:953) target         = 1024
[2010-07-19 14:06:41 2682] DEBUG (image:954) vcpus          = 1
[2010-07-19 14:06:41 2682] DEBUG (image:955) vcpu_avail     = 1
[2010-07-19 14:06:41 2682] DEBUG (image:956) acpi           = 1
[2010-07-19 14:06:41 2682] DEBUG (image:957) apic           = 1
[2010-07-19 14:06:41 2682] INFO (XendDomainInfo:2367) createDevice: vfb : {'vncunused': 1, 'vnclisten': '0.0.0.0', 'vnc': '1', 'uuid': 'f902063e-84bc-531b-667a-e40554210618', 'other_config': {'vncunused': 1, 'vnclisten': '0.0.0.0', 'vnc': '1'}}
[2010-07-19 14:06:41 2682] DEBUG (DevController:95) DevController: writing {'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend/vfb/1/0'} to /local/domain/1/device/vfb/0.
[2010-07-19 14:06:41 2682] DEBUG (DevController:97) DevController: writing {'vncunused': '1', 'domain': 'svm', 'frontend': '/local/domain/1/device/vfb/0', 'uuid': 'f902063e-84bc-531b-667a-e40554210618', 'frontend-id': '1', 'vnclisten': '0.0.0.0', 'state': '1', 'online': '1', 'vnc': '1'} to /local/domain/0/backend/vfb/1/0.
[2010-07-19 14:06:41 2682] INFO (XendDomainInfo:2367) createDevice: tap : {'bootable': 1, 'uname': 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd', 'mode': 'w', 'dev': 'xvda:sda1', 'uuid': '6d2c4c25-35a5-9880-3cf0-7bd345a62824'}
[2010-07-19 14:06:41 2682] DEBUG (DevController:95) DevController: writing {'backend-id': '0', 'virtual-device': '51712', 'device-type': 'sda1', 'state': '1', 'backend': '/local/domain/0/backend/tap/1/51712'} to /local/domain/1/device/vbd/51712.
[2010-07-19 14:06:41 2682] DEBUG (DevController:97) DevController: writing {'domain': 'svm', 'frontend': '/local/domain/1/device/vbd/51712', 'uuid': '6d2c4c25-35a5-9880-3cf0-7bd345a62824', 'bootable': '1', 'dev': 'xvda', 'state': '1', 'params': 'tapdisk:vhd:/mnt/win2008sp2.vhd', 'mode': 'w', 'online': '1', 'frontend-id': '1', 'type': 'tap'} to /local/domain/0/backend/tap/1/51712.
[2010-07-19 14:06:41 2682] INFO (XendDomainInfo:2367) createDevice: vif : {'bridge': 'eth0', 'model': 'e1000', 'mac': '00:16:3e:00:20:02', 'uuid': 'b88e79ee-7166-5667-b92e-0ea8ffa5d1ce'}
[2010-07-19 14:06:41 2682] DEBUG (DevController:95) DevController: writing {'backend-id': '0', 'mac': '00:16:3e:00:20:02', 'handle': '0', 'state': '1', 'backend': '/local/domain/0/backend/vif/1/0'} to /local/domain/1/device/vif/0.
[2010-07-19 14:06:41 2682] DEBUG (DevController:97) DevController: writing {'bridge': 'eth0', 'domain': 'svm', 'handle': '0', 'uuid': 'b88e79ee-7166-5667-b92e-0ea8ffa5d1ce', 'script': '/etc/xen/scripts/vif-bridge', 'mac': '00:16:3e:00:20:02', 'frontend-id': '1', 'state': '1', 'online': '1', 'frontend': '/local/domain/1/device/vif/0', 'model': 'e1000'} to /local/domain/0/backend/vif/1/0.
[2010-07-19 14:06:41 2682] INFO (image:418) spawning device models: /usr/lib64/xen/bin/qemu-dm ['/usr/lib64/xen/bin/qemu-dm', '-d', '1', '-domain-name', 'svm', '-videoram', '4', '-vnc', '0.0.0.0:0', '-vncunused', '-vcpus', '1', '-vcpu_avail', '0x1', '-boot', 'c', '-serial', 'pty', '-acpi', '-usbdevice', 'tablet', '-net', 'nic,vlan=1,macaddr=00:16:3e:00:20:02,model=e1000', '-net', 'tap,vlan=1,ifname=tap1.0,bridge=eth0', '-M', 'xenfv']
[2010-07-19 14:06:41 2682] INFO (image:467) device model pid: 2924
[2010-07-19 14:06:41 2682] INFO (image:590) waiting for sentinel_fifo
[2010-07-19 14:06:41 2682] DEBUG (XendDomainInfo:3400) Storing VM details: {'on_xend_stop': 'ignore', 'shadow_memory': '9', 'uuid': '83f19c26-d28e-3306-0d51-c98a215cd7df', 'on_reboot': 'restart', 'start_time': '1279573601.8', 'on_poweroff': 'destroy', 'bootloader_args': '', 'on_xend_start': 'ignore', 'on_crash': 'destroy', 'xend/restart_count': '0', 'vcpus': '1', 'vcpu_avail': '1', 'bootloader': '', 'image': '(hvm (kernel ) (superpages 0) (videoram 4) (hpet 0) (stdvga 0) (vnclisten 0.0.0.0) (loader /usr/lib64/xen/boot/hvmloader) (xen_platform_pci 1) (rtc_timeoffset 0) (pci ()) (hap 1) (localtime 0) (timer_mode 1) (pci_msitranslate 1) (oos 1) (apic 1) (sdl 0) (usbdevice tablet) (vpt_align 1) (vncconsole 1) (serial pty) (vncunused 1) (boot c) (pae 1) (viridian 0) (acpi 1) (vnc 1) (nographic 0) (nomigrate 0) (usb 0) (tsc_mode 0) (guest_os_type default) (device_model /usr/lib64/xen/bin/qemu-dm) (pci_power_mgmt 0) (xauthority /root/.Xauthority) (isa 0) (notes (SUSPEND_CANCEL 1)))', 'name': 'svm'}
[2010-07-19 14:06:41 2682] DEBUG (XendDomainInfo:1804) Storing domain details: {'console/port': '3', 'description': '', 'console/limit': '1048576', 'store/port': '2', 'vm': '/vm/83f19c26-d28e-3306-0d51-c98a215cd7df', 'domid': '1', 'image/suspend-cancel': '1', 'cpu/0/availability': 'online', 'memory/target': '1048576', 'control/platform-feature-multiprocessor-suspend': '1', 'store/ring-ref': '1044476', 'console/type': 'ioemu', 'name': 'svm'}
[2010-07-19 14:06:41 2682] DEBUG (DevController:95) DevController: writing {'state': '1', 'backend-id': '0', 'backend': '/local/domain/0/backend/console/1/0'} to /local/domain/1/device/console/0.
[2010-07-19 14:06:41 2682] DEBUG (DevController:97) DevController: writing {'domain': 'svm', 'frontend': '/local/domain/1/device/console/0', 'uuid': '290b84a1-a4a2-03eb-ba65-0a348fdcbdc4', 'frontend-id': '1', 'state': '1', 'location': '3', 'online': '1', 'protocol': 'vt100'} to /local/domain/0/backend/console/1/0.
[2010-07-19 14:06:41 2682] DEBUG (XendDomainInfo:1891) XendDomainInfo.handleShutdownWatch
[2010-07-19 14:06:41 2682] DEBUG (DevController:139) Waiting for devices tap2.
[2010-07-19 14:06:41 2682] DEBUG (DevController:139) Waiting for devices vif.
[2010-07-19 14:06:41 2682] DEBUG (DevController:144) Waiting for 0.
[2010-07-19 14:06:41 2682] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/1/0/hotplug-status.
[2010-07-19 14:06:42 2682] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vif/1/0/hotplug-status.
[2010-07-19 14:06:42 2682] DEBUG (DevController:642) hotplugStatusCallback 1.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices vkbd.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices ioports.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices tap.
[2010-07-19 14:06:42 2682] DEBUG (DevController:144) Waiting for 51712.
[2010-07-19 14:06:42 2682] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/tap/1/51712/hotplug-status.
[2010-07-19 14:06:42 2682] DEBUG (DevController:642) hotplugStatusCallback 1.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices vif2.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices console.
[2010-07-19 14:06:42 2682] DEBUG (DevController:144) Waiting for 0.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices vscsi.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices vbd.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices irq.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices vfb.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices pci.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices vusb.
[2010-07-19 14:06:42 2682] DEBUG (DevController:139) Waiting for devices vtpm.
[2010-07-19 14:06:42 2682] INFO (XendDomain:1206) Domain svm (1) unpaused.
[2010-07-19 14:07:15 2682] INFO (XendDomainInfo:2088) Domain has shutdown: name=svm id=1 reason=poweroff.
[2010-07-19 14:07:15 2682] DEBUG (XendDomainInfo:3053) XendDomainInfo.destroy: domid=1
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:2411) Destroying device model
[2010-07-19 14:07:16 2682] INFO (image:615) svm device model terminated
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:2418) Releasing devices
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:2424) Removing vif/0
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:2424) Removing tap/51712
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = tap, device = tap/51712
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:2424) Removing console/0
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = console, device = console/0
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:2424) Removing vfb/0
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = vfb, device = vfb/0
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:2416) No device model
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:2418) Releasing devices
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:2424) Removing vif/0
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:2424) Removing tap/51712
[2010-07-19 14:07:16 2682] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = tap, device = tap/51712

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

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

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Daniel Stodden]

On Mon, 2010-07-19 at 17:27 -0400, Dante Cinco wrote:
> I'm getting this message (subject line) in daemon.log every time I
> start or restart xend. I'm not sure if this is related to the fact
> that I cannot boot up my Windows domU from a VHD file. The Windows
> domU was working fine with Xen 4.0.0 (with 2.6.32.14 dom0 kernel).
> When I upgraded to Xen 4.0.1-rc4 (with 2.6.32.16 dom0 kernel), I can
> no long boot the Windows domU from VHD. The VNC console for the
> Windows HVM has this message:
> 
> Booting from Hard Disk ...
> Boot from Hard Disk failed; could not read the boot disk
> 
> No bootable device.
> Powering off in 30 seconds.
> 
> Here's the disk setting in my Windows domU config file: disk =
> ['tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w']
> 
> Here's the other BLKTAPCTRL messages in daemon.log:
> 
> BLKTAPCTRL[2444]: blktapctrl.c:790: blktapctrl: v1.0.0
> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (aio)]
> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (sync)]
> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [vmware image (vmdk)]
> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [ramdisk image (ram)]
> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow disk (qcow)]
> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)]
> BLKTAPCTRL[2444]: blktapctrl_linux.c:86: blktap0 open failed
> BLKTAPCTRL[2444]: blktapctrl.c:859: couldn't open blktap interface
> BLKTAPCTRL[2444]: blktapctrl.c:922: Unable to start blktapctrl

Let's kill the beast.

Blktapctrl is a residual from blktap1 nobody ever bothered to reliably
prevent from trying to start on pvops, unfortunately.

I had a bit of an aha-experience today trying to repro your issue,
before I figured out that you're just running 2.6.3x. It seems to be the
case that the chrdev majors assignment, both dynamically allocated by
blktap1 and -2, tend to be identical when moving from a xen kernel with
blktap1 enabled, to pvops, which only has blktap2.

Which means if somebody starts blktapctrl, it may happily try to open
the kernel link of the first blktap2 (/dev/xen/blktap-2/blktap0) device
as the control node for blktap1 (/dev/xen/blktap0).

In really unfortunate cases, that code around blktapctrl.c:859 above
will suceed, even managing to provoke a stacktrace. Normally wouldn't
happen, in this case I happened to have some somewhat wedged trainwreck
minor number 0 set up, which wasn't aquired by a real tapdisk already.

Should drop blktapctrl from xend start altogether, to avoid confusion in
in both software and users.

Or maybe at least do an environment check and fail with a more friendly
last word on blktap1 matters.

That, of course, nowhere explains your w2k8 problem, right?

Daniel

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Dante Cinco]

Daniel,

I'm using 2.6.32 pv-ops dom0 kernel. How do I check if it's using
blktap2 instead of blktap1? If I look at /dev and /dev/xen, here's
what I see?

kaan-11:/boot# ls -l /dev/blktap-control
crw-rw---- 1 root root 10, 60 Jul 21 16:45 /dev/blktap-control
kaan-11:/boot# ls -l /dev/xen/
total 0
crw-rw---- 1 root root 10, 54 Jul 21 16:45 evtchn
crw-rw---- 1 root root 10, 61 Jul 21 16:45 gntdev

Here's part of my "xm info"

release                : 2.6.32
version                : #1 SMP Tue Jul 20 11:33:27 PDT 2010
machine                : x86_64
xen_major              : 4
xen_minor              : 1
xen_extra              : -unstable
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

Some additional info: When I tried bringing up an HVM win2k8 from VHD,
I see the following in qemu-dm-svm.log

Using xvda for guest's hda
Strip off blktap sub-type prefix to vhd:/mnt/win2008sp2.vhd (drv 'tapdisk')
qemu: type (image format) 'tapdisk' unknown for vbd
'/local/domain/0/backend/tap/1/51712/type' or image
'vhd:/mnt/win2008sp2.vhd'

Does this look like it's related to blktap1 vs blktap2?

Thanks.

Dante


On Mon, Jul 19, 2010 at 7:30 PM, Daniel Stodden
<daniel.stodden@citrix.com> wrote:
> On Mon, 2010-07-19 at 17:27 -0400, Dante Cinco wrote:
>> I'm getting this message (subject line) in daemon.log every time I
>> start or restart xend. I'm not sure if this is related to the fact
>> that I cannot boot up my Windows domU from a VHD file. The Windows
>> domU was working fine with Xen 4.0.0 (with 2.6.32.14 dom0 kernel).
>> When I upgraded to Xen 4.0.1-rc4 (with 2.6.32.16 dom0 kernel), I can
>> no long boot the Windows domU from VHD. The VNC console for the
>> Windows HVM has this message:
>>
>> Booting from Hard Disk ...
>> Boot from Hard Disk failed; could not read the boot disk
>>
>> No bootable device.
>> Powering off in 30 seconds.
>>
>> Here's the disk setting in my Windows domU config file: disk =
>> ['tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w']
>>
>> Here's the other BLKTAPCTRL messages in daemon.log:
>>
>> BLKTAPCTRL[2444]: blktapctrl.c:790: blktapctrl: v1.0.0
>> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (aio)]
>> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (sync)]
>> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [vmware image (vmdk)]
>> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [ramdisk image (ram)]
>> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow disk (qcow)]
>> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)]
>> BLKTAPCTRL[2444]: blktapctrl_linux.c:86: blktap0 open failed
>> BLKTAPCTRL[2444]: blktapctrl.c:859: couldn't open blktap interface
>> BLKTAPCTRL[2444]: blktapctrl.c:922: Unable to start blktapctrl
>
> Let's kill the beast.
>
> Blktapctrl is a residual from blktap1 nobody ever bothered to reliably
> prevent from trying to start on pvops, unfortunately.
>
> I had a bit of an aha-experience today trying to repro your issue,
> before I figured out that you're just running 2.6.3x. It seems to be the
> case that the chrdev majors assignment, both dynamically allocated by
> blktap1 and -2, tend to be identical when moving from a xen kernel with
> blktap1 enabled, to pvops, which only has blktap2.
>
> Which means if somebody starts blktapctrl, it may happily try to open
> the kernel link of the first blktap2 (/dev/xen/blktap-2/blktap0) device
> as the control node for blktap1 (/dev/xen/blktap0).
>
> In really unfortunate cases, that code around blktapctrl.c:859 above
> will suceed, even managing to provoke a stacktrace. Normally wouldn't
> happen, in this case I happened to have some somewhat wedged trainwreck
> minor number 0 set up, which wasn't aquired by a real tapdisk already.
>
> Should drop blktapctrl from xend start altogether, to avoid confusion in
> in both software and users.
>
> Or maybe at least do an environment check and fail with a more friendly
> last word on blktap1 matters.
>
> That, of course, nowhere explains your w2k8 problem, right?
>
> Daniel
>
>

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Daniel Stodden]

On Wed, 2010-07-21 at 20:11 -0400, Dante Cinco wrote:
> Daniel,
> 
> I'm using 2.6.32 pv-ops dom0 kernel. How do I check if it's using
> blktap2 instead of blktap1? If I look at /dev and /dev/xen, here's
> what I see?

With pvops the formula is pretty simple.
Blktap1 doesn't exist, you have to run blktap2.

> kaan-11:/boot# ls -l /dev/blktap-control
> crw-rw---- 1 root root 10, 60 Jul 21 16:45 /dev/blktap-control
> kaan-11:/boot# ls -l /dev/xen/
> total 0
> crw-rw---- 1 root root 10, 54 Jul 21 16:45 evtchn
> crw-rw---- 1 root root 10, 61 Jul 21 16:45 gntdev
> 
> Here's part of my "xm info"
> 
> release                : 2.6.32
> version                : #1 SMP Tue Jul 20 11:33:27 PDT 2010
> machine                : x86_64
> xen_major              : 4
> xen_minor              : 1
> xen_extra              : -unstable
> 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
> 
> Some additional info: When I tried bringing up an HVM win2k8 from VHD,
> I see the following in qemu-dm-svm.log
> 
> Using xvda for guest's hda
> Strip off blktap sub-type prefix to vhd:/mnt/win2008sp2.vhd (drv 'tapdisk')

Uhm. Looks like common image locator madness.

I think this stuff has seen changes again.

So vhd:/mnt/win2008.vhd is ends up as the path, and tapdisk the driver?\
That won't work.

What does you cfg look like? 

Guessing, do you have a :tapdisk: substring in there? I used to have
one.

Could you try stripping it, down to "tap:vhd:/mnt/win2008sp2.vhd"?

Thanks,
Daniel

> qemu: type (image format) 'tapdisk' unknown for vbd
> '/local/domain/0/backend/tap/1/51712/type' or image
> 'vhd:/mnt/win2008sp2.vhd'
> 
> Does this look like it's related to blktap1 vs blktap2?
> 
> Thanks.
> 
> Dante
> 
> 
> On Mon, Jul 19, 2010 at 7:30 PM, Daniel Stodden
> <daniel.stodden@citrix.com> wrote:
> > On Mon, 2010-07-19 at 17:27 -0400, Dante Cinco wrote:
> >> I'm getting this message (subject line) in daemon.log every time I
> >> start or restart xend. I'm not sure if this is related to the fact
> >> that I cannot boot up my Windows domU from a VHD file. The Windows
> >> domU was working fine with Xen 4.0.0 (with 2.6.32.14 dom0 kernel).
> >> When I upgraded to Xen 4.0.1-rc4 (with 2.6.32.16 dom0 kernel), I can
> >> no long boot the Windows domU from VHD. The VNC console for the
> >> Windows HVM has this message:
> >>
> >> Booting from Hard Disk ...
> >> Boot from Hard Disk failed; could not read the boot disk
> >>
> >> No bootable device.
> >> Powering off in 30 seconds.
> >>
> >> Here's the disk setting in my Windows domU config file: disk =
> >> ['tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w']
> >>
> >> Here's the other BLKTAPCTRL messages in daemon.log:
> >>
> >> BLKTAPCTRL[2444]: blktapctrl.c:790: blktapctrl: v1.0.0
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (aio)]
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (sync)]
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [vmware image (vmdk)]
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [ramdisk image (ram)]
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow disk (qcow)]
> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)]
> >> BLKTAPCTRL[2444]: blktapctrl_linux.c:86: blktap0 open failed
> >> BLKTAPCTRL[2444]: blktapctrl.c:859: couldn't open blktap interface
> >> BLKTAPCTRL[2444]: blktapctrl.c:922: Unable to start blktapctrl
> >
> > Let's kill the beast.
> >
> > Blktapctrl is a residual from blktap1 nobody ever bothered to reliably
> > prevent from trying to start on pvops, unfortunately.
> >
> > I had a bit of an aha-experience today trying to repro your issue,
> > before I figured out that you're just running 2.6.3x. It seems to be the
> > case that the chrdev majors assignment, both dynamically allocated by
> > blktap1 and -2, tend to be identical when moving from a xen kernel with
> > blktap1 enabled, to pvops, which only has blktap2.
> >
> > Which means if somebody starts blktapctrl, it may happily try to open
> > the kernel link of the first blktap2 (/dev/xen/blktap-2/blktap0) device
> > as the control node for blktap1 (/dev/xen/blktap0).
> >
> > In really unfortunate cases, that code around blktapctrl.c:859 above
> > will suceed, even managing to provoke a stacktrace. Normally wouldn't
> > happen, in this case I happened to have some somewhat wedged trainwreck
> > minor number 0 set up, which wasn't aquired by a real tapdisk already.
> >
> > Should drop blktapctrl from xend start altogether, to avoid confusion in
> > in both software and users.
> >
> > Or maybe at least do an environment check and fail with a more friendly
> > last word on blktap1 matters.
> >
> > That, of course, nowhere explains your w2k8 problem, right?
> >
> > Daniel
> >
> >

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Dante Cinco]

Daniel,

My cfg has this: disk = [ 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]

If I remove tapdisk, I get this error:

Error: need more than 1 value to unpack

Here's a more basic question: How do I check if my dom0 kernel has
blktap2? Is the presence of /dev/xen/blktap-2 (such as below) a
necessary indicator?
kaan-20:~# ls -l /dev/xen/blktap-2
crw------- 1 root root 253,  0 Jul 21 20:29 blktap0
crw------- 1 root root  10, 59 Jul 21 20:29 control
brw------- 1 root root 253,  0 Jul 21 20:29 tapdev0

The system with Xen 4.0.1-rc4 and 2.6.32.16 where VHD does not work
does not have any blktap in /dev/xen:
kaan-11:~# ls -l /dev/xen
crw-rw---- 1 root root 10, 54 Jul 22 01:57 evtchn
crw-rw---- 1 root root 10, 61 Jul 22 01:57 gntdev
Does this mean this dom0 kernel does not have the blktap driver?

The kernel config file for the system where VHD does not work contains
the following. Is this correct?
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_BLKDEV_TAP=y
CONFIG_XEN_BLKBACK_PAGEMAP=y

Thanks.

Dante


On Wed, Jul 21, 2010 at 7:02 PM, Daniel Stodden
<daniel.stodden@citrix.com> wrote:
> On Wed, 2010-07-21 at 20:11 -0400, Dante Cinco wrote:
>> Daniel,
>>
>> I'm using 2.6.32 pv-ops dom0 kernel. How do I check if it's using
>> blktap2 instead of blktap1? If I look at /dev and /dev/xen, here's
>> what I see?
>
> With pvops the formula is pretty simple.
> Blktap1 doesn't exist, you have to run blktap2.
>
>> kaan-11:/boot# ls -l /dev/blktap-control
>> crw-rw---- 1 root root 10, 60 Jul 21 16:45 /dev/blktap-control
>> kaan-11:/boot# ls -l /dev/xen/
>> total 0
>> crw-rw---- 1 root root 10, 54 Jul 21 16:45 evtchn
>> crw-rw---- 1 root root 10, 61 Jul 21 16:45 gntdev
>>
>> Here's part of my "xm info"
>>
>> release                : 2.6.32
>> version                : #1 SMP Tue Jul 20 11:33:27 PDT 2010
>> machine                : x86_64
>> xen_major              : 4
>> xen_minor              : 1
>> xen_extra              : -unstable
>> 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
>>
>> Some additional info: When I tried bringing up an HVM win2k8 from VHD,
>> I see the following in qemu-dm-svm.log
>>
>> Using xvda for guest's hda
>> Strip off blktap sub-type prefix to vhd:/mnt/win2008sp2.vhd (drv 'tapdisk')
>
> Uhm. Looks like common image locator madness.
>
> I think this stuff has seen changes again.
>
> So vhd:/mnt/win2008.vhd is ends up as the path, and tapdisk the driver?\
> That won't work.
>
> What does you cfg look like?
>
> Guessing, do you have a :tapdisk: substring in there? I used to have
> one.
>
> Could you try stripping it, down to "tap:vhd:/mnt/win2008sp2.vhd"?
>
> Thanks,
> Daniel
>
>> qemu: type (image format) 'tapdisk' unknown for vbd
>> '/local/domain/0/backend/tap/1/51712/type' or image
>> 'vhd:/mnt/win2008sp2.vhd'
>>
>> Does this look like it's related to blktap1 vs blktap2?
>>
>> Thanks.
>>
>> Dante
>>
>>
>> On Mon, Jul 19, 2010 at 7:30 PM, Daniel Stodden
>> <daniel.stodden@citrix.com> wrote:
>> > On Mon, 2010-07-19 at 17:27 -0400, Dante Cinco wrote:
>> >> I'm getting this message (subject line) in daemon.log every time I
>> >> start or restart xend. I'm not sure if this is related to the fact
>> >> that I cannot boot up my Windows domU from a VHD file. The Windows
>> >> domU was working fine with Xen 4.0.0 (with 2.6.32.14 dom0 kernel).
>> >> When I upgraded to Xen 4.0.1-rc4 (with 2.6.32.16 dom0 kernel), I can
>> >> no long boot the Windows domU from VHD. The VNC console for the
>> >> Windows HVM has this message:
>> >>
>> >> Booting from Hard Disk ...
>> >> Boot from Hard Disk failed; could not read the boot disk
>> >>
>> >> No bootable device.
>> >> Powering off in 30 seconds.
>> >>
>> >> Here's the disk setting in my Windows domU config file: disk =
>> >> ['tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w']
>> >>
>> >> Here's the other BLKTAPCTRL messages in daemon.log:
>> >>
>> >> BLKTAPCTRL[2444]: blktapctrl.c:790: blktapctrl: v1.0.0
>> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (aio)]
>> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [raw image (sync)]
>> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [vmware image (vmdk)]
>> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [ramdisk image (ram)]
>> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow disk (qcow)]
>> >> BLKTAPCTRL[2444]: blktapctrl.c:792: Found driver: [qcow2 disk (qcow2)]
>> >> BLKTAPCTRL[2444]: blktapctrl_linux.c:86: blktap0 open failed
>> >> BLKTAPCTRL[2444]: blktapctrl.c:859: couldn't open blktap interface
>> >> BLKTAPCTRL[2444]: blktapctrl.c:922: Unable to start blktapctrl
>> >
>> > Let's kill the beast.
>> >
>> > Blktapctrl is a residual from blktap1 nobody ever bothered to reliably
>> > prevent from trying to start on pvops, unfortunately.
>> >
>> > I had a bit of an aha-experience today trying to repro your issue,
>> > before I figured out that you're just running 2.6.3x. It seems to be the
>> > case that the chrdev majors assignment, both dynamically allocated by
>> > blktap1 and -2, tend to be identical when moving from a xen kernel with
>> > blktap1 enabled, to pvops, which only has blktap2.
>> >
>> > Which means if somebody starts blktapctrl, it may happily try to open
>> > the kernel link of the first blktap2 (/dev/xen/blktap-2/blktap0) device
>> > as the control node for blktap1 (/dev/xen/blktap0).
>> >
>> > In really unfortunate cases, that code around blktapctrl.c:859 above
>> > will suceed, even managing to provoke a stacktrace. Normally wouldn't
>> > happen, in this case I happened to have some somewhat wedged trainwreck
>> > minor number 0 set up, which wasn't aquired by a real tapdisk already.
>> >
>> > Should drop blktapctrl from xend start altogether, to avoid confusion in
>> > in both software and users.
>> >
>> > Or maybe at least do an environment check and fail with a more friendly
>> > last word on blktap1 matters.
>> >
>> > That, of course, nowhere explains your w2k8 problem, right?
>> >
>> > Daniel
>> >
>> >
>
>
>

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Daniel Stodden]

On Thu, 2010-07-22 at 12:59 -0400, Dante Cinco wrote:
> Daniel,
> 
> My cfg has this: disk = [ 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
> 
> If I remove tapdisk, I get this error:
> 
> Error: need more than 1 value to unpack
> 
> Here's a more basic question: How do I check if my dom0 kernel has
> blktap2? Is the presence of /dev/xen/blktap-2 (such as below) a
> necessary indicator?
> kaan-20:~# ls -l /dev/xen/blktap-2
> crw------- 1 root root 253,  0 Jul 21 20:29 blktap0
> crw------- 1 root root  10, 59 Jul 21 20:29 control
> brw------- 1 root root 253,  0 Jul 21 20:29 tapdev0

No. These will be generated by udev in the future, in which case this
would be indication, too. But right now the toolstack mknods them if
they don't exist.

You should see a /sys/class/blktap2 directory and 'tapdev' and 'blktap2'
device entries in /proc/devices.

> The system with Xen 4.0.1-rc4 and 2.6.32.16 where VHD does not work
> does not have any blktap in /dev/xen:
> kaan-11:~# ls -l /dev/xen
> crw-rw---- 1 root root 10, 54 Jul 22 01:57 evtchn
> crw-rw---- 1 root root 10, 61 Jul 22 01:57 gntdev
> Does this mean this dom0 kernel does not have the blktap driver?
> 
> The kernel config file for the system where VHD does not work contains
> the following. Is this correct?
> CONFIG_XEN_BLKDEV_FRONTEND=m
> CONFIG_XEN_BLKDEV_BACKEND=y
> CONFIG_XEN_BLKDEV_TAP=y
> CONFIG_XEN_BLKBACK_PAGEMAP=y

Yep.

Problem is I'm not very good with xen-stable, as you might have already
guessed.

There's a lot of 'tap' vs. 'tap2' stuff in the python sources.

How about tap2:tapdisk:...?

:>

Daniel

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Dante Cinco]

Daniel,

You got it right with tap2 (instead of tap). That's the key.

So with Xen 4.0.0 and 2.6.32.14 it's: disk = [
'tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]

and with Xen 4.0.1-rc4 and 2.6.32.16 it's: disk = [
'tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]

Very subtle change but makes a world of difference. My Windows 2008
domU is now booting from a VHD file.

Here's what I see in /sys/devices/virtual/blktap2/blktap0/debug:
vhd:/mnt/win2008sp2.vhd (253:0), refcnt: 0, dev_inuse: 0x0000001e
capacity: 0x3200000, sector size: 0x200, device users: 2
pending requests: 0

And in /var/log/xen/ qemu-dm-svm.log:
Using xvda for guest's hda
Using file /dev/xen/blktap-2/tapdev0 in read-write mode

Thanks a lot for your help.

Dante


On Thu, Jul 22, 2010 at 1:11 PM, Daniel Stodden
<daniel.stodden@citrix.com> wrote:
> On Thu, 2010-07-22 at 12:59 -0400, Dante Cinco wrote:
>> Daniel,
>>
>> My cfg has this: disk = [ 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
>>
>> If I remove tapdisk, I get this error:
>>
>> Error: need more than 1 value to unpack
>>
>> Here's a more basic question: How do I check if my dom0 kernel has
>> blktap2? Is the presence of /dev/xen/blktap-2 (such as below) a
>> necessary indicator?
>> kaan-20:~# ls -l /dev/xen/blktap-2
>> crw------- 1 root root 253,  0 Jul 21 20:29 blktap0
>> crw------- 1 root root  10, 59 Jul 21 20:29 control
>> brw------- 1 root root 253,  0 Jul 21 20:29 tapdev0
>
> No. These will be generated by udev in the future, in which case this
> would be indication, too. But right now the toolstack mknods them if
> they don't exist.
>
> You should see a /sys/class/blktap2 directory and 'tapdev' and 'blktap2'
> device entries in /proc/devices.
>
>> The system with Xen 4.0.1-rc4 and 2.6.32.16 where VHD does not work
>> does not have any blktap in /dev/xen:
>> kaan-11:~# ls -l /dev/xen
>> crw-rw---- 1 root root 10, 54 Jul 22 01:57 evtchn
>> crw-rw---- 1 root root 10, 61 Jul 22 01:57 gntdev
>> Does this mean this dom0 kernel does not have the blktap driver?
>>
>> The kernel config file for the system where VHD does not work contains
>> the following. Is this correct?
>> CONFIG_XEN_BLKDEV_FRONTEND=m
>> CONFIG_XEN_BLKDEV_BACKEND=y
>> CONFIG_XEN_BLKDEV_TAP=y
>> CONFIG_XEN_BLKBACK_PAGEMAP=y
>
> Yep.
>
> Problem is I'm not very good with xen-stable, as you might have already
> guessed.
>
> There's a lot of 'tap' vs. 'tap2' stuff in the python sources.
>
> How about tap2:tapdisk:...?
>
> :>
>
> Daniel
>
>

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Pasi Kärkkäinen]

On Thu, Jul 22, 2010 at 01:46:35PM -0700, Dante Cinco wrote:
> Daniel,
> 
> You got it right with tap2 (instead of tap). That's the key.
> 
> So with Xen 4.0.0 and 2.6.32.14 it's: disk = [
> 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
> 
> and with Xen 4.0.1-rc4 and 2.6.32.16 it's: disk = [
> 'tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
> 
> Very subtle change but makes a world of difference. My Windows 2008
> domU is now booting from a VHD file.
> 

Uhm.. is this change intentional? 

-- Pasi


> Here's what I see in /sys/devices/virtual/blktap2/blktap0/debug:
> vhd:/mnt/win2008sp2.vhd (253:0), refcnt: 0, dev_inuse: 0x0000001e
> capacity: 0x3200000, sector size: 0x200, device users: 2
> pending requests: 0
> 
> And in /var/log/xen/ qemu-dm-svm.log:
> Using xvda for guest's hda
> Using file /dev/xen/blktap-2/tapdev0 in read-write mode
> 
> Thanks a lot for your help.
> 
> Dante
> 
> 
> On Thu, Jul 22, 2010 at 1:11 PM, Daniel Stodden
> <daniel.stodden@citrix.com> wrote:
> > On Thu, 2010-07-22 at 12:59 -0400, Dante Cinco wrote:
> >> Daniel,
> >>
> >> My cfg has this: disk = [ 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
> >>
> >> If I remove tapdisk, I get this error:
> >>
> >> Error: need more than 1 value to unpack
> >>
> >> Here's a more basic question: How do I check if my dom0 kernel has
> >> blktap2? Is the presence of /dev/xen/blktap-2 (such as below) a
> >> necessary indicator?
> >> kaan-20:~# ls -l /dev/xen/blktap-2
> >> crw------- 1 root root 253,  0 Jul 21 20:29 blktap0
> >> crw------- 1 root root  10, 59 Jul 21 20:29 control
> >> brw------- 1 root root 253,  0 Jul 21 20:29 tapdev0
> >
> > No. These will be generated by udev in the future, in which case this
> > would be indication, too. But right now the toolstack mknods them if
> > they don't exist.
> >
> > You should see a /sys/class/blktap2 directory and 'tapdev' and 'blktap2'
> > device entries in /proc/devices.
> >
> >> The system with Xen 4.0.1-rc4 and 2.6.32.16 where VHD does not work
> >> does not have any blktap in /dev/xen:
> >> kaan-11:~# ls -l /dev/xen
> >> crw-rw---- 1 root root 10, 54 Jul 22 01:57 evtchn
> >> crw-rw---- 1 root root 10, 61 Jul 22 01:57 gntdev
> >> Does this mean this dom0 kernel does not have the blktap driver?
> >>
> >> The kernel config file for the system where VHD does not work contains
> >> the following. Is this correct?
> >> CONFIG_XEN_BLKDEV_FRONTEND=m
> >> CONFIG_XEN_BLKDEV_BACKEND=y
> >> CONFIG_XEN_BLKDEV_TAP=y
> >> CONFIG_XEN_BLKBACK_PAGEMAP=y
> >
> > Yep.
> >
> > Problem is I'm not very good with xen-stable, as you might have already
> > guessed.
> >
> > There's a lot of 'tap' vs. 'tap2' stuff in the python sources.
> >
> > How about tap2:tapdisk:...?
> >
> > :>
> >
> > Daniel
> >
> >
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Keir Fraser]

On 22/07/2010 22:10, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:

>> You got it right with tap2 (instead of tap). That's the key.
>> 
>> So with Xen 4.0.0 and 2.6.32.14 it's: disk = [
>> 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
>> 
>> and with Xen 4.0.1-rc4 and 2.6.32.16 it's: disk = [
>> 'tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
>> 
>> Very subtle change but makes a world of difference. My Windows 2008
>> domU is now booting from a VHD file.
>> 
> 
> Uhm.. is this change intentional?

xen-unstable:21338 and xen-4.0-testing:21140. So yes.

 -- Keir

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Daniel Stodden]

On Fri, 2010-07-23 at 03:07 -0400, Keir Fraser wrote:
> On 22/07/2010 22:10, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
> 
> >> You got it right with tap2 (instead of tap). That's the key.
> >> 
> >> So with Xen 4.0.0 and 2.6.32.14 it's: disk = [
> >> 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
> >> 
> >> and with Xen 4.0.1-rc4 and 2.6.32.16 it's: disk = [
> >> 'tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
> >> 
> >> Very subtle change but makes a world of difference. My Windows 2008
> >> domU is now booting from a VHD file.
> >> 
> > 
> > Uhm.. is this change intentional?
> 
> xen-unstable:21338 and xen-4.0-testing:21140. So yes.

That sounds like a lot of fallout on xen-users.
Especially for people who just want their guests to boot.

Maybe the whole notation should have rather been some _optional_ blktap
= {1|2} cfg key, only for those who actually care?

[As much as the whole disk notation should probably always just have
been <type>:<path>, with a separately configurable <type> -> <backend>
mapping for people who want to override backend choices (such
file->loopback vs file->aio).]

I guess the latter cannot be fixed. But maybe the former?

Daniel

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Keir Fraser]

On 25/07/2010 10:27, "Daniel Stodden" <daniel.stodden@citrix.com> wrote:

>>> Uhm.. is this change intentional?
>> 
>> xen-unstable:21338 and xen-4.0-testing:21140. So yes.
> 
> That sounds like a lot of fallout on xen-users.
> Especially for people who just want their guests to boot.
> 
> Maybe the whole notation should have rather been some _optional_ blktap
> = {1|2} cfg key, only for those who actually care?
> 
> [As much as the whole disk notation should probably always just have
> been <type>:<path>, with a separately configurable <type> -> <backend>
> mapping for people who want to override backend choices (such
> file->loopback vs file->aio).]
> 
> I guess the latter cannot be fixed. But maybe the former?

I don't personally have an opinion on it. I'm pretty sure Jim was having
other problems if this distinction wasn't made in the config file. But
perhaps it was rash to backport it to 4.0-testing, all the same.

 -- Keir

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed

[Ian Campbell]

On Sun, 2010-07-25 at 10:27 +0100, Daniel Stodden wrote:
> On Fri, 2010-07-23 at 03:07 -0400, Keir Fraser wrote:
> > On 22/07/2010 22:10, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
> > 
> > >> You got it right with tap2 (instead of tap). That's the key.
> > >> 
> > >> So with Xen 4.0.0 and 2.6.32.14 it's: disk = [
> > >> 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
> > >> 
> > >> and with Xen 4.0.1-rc4 and 2.6.32.16 it's: disk = [
> > >> 'tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
> > >> 
> > >> Very subtle change but makes a world of difference. My Windows 2008
> > >> domU is now booting from a VHD file.
> > >> 
> > > 
> > > Uhm.. is this change intentional?
> > 
> > xen-unstable:21338 and xen-4.0-testing:21140. So yes.
> 
> That sounds like a lot of fallout on xen-users.
> Especially for people who just want their guests to boot.
> 
> Maybe the whole notation should have rather been some _optional_ blktap
> = {1|2} cfg key, only for those who actually care?

FWIW, I completely agree with this.

> 
> [As much as the whole disk notation should probably always just have
> been <type>:<path>, with a separately configurable <type> -> <backend>
> mapping for people who want to override backend choices (such
> file->loopback vs file->aio).]
> 
> I guess the latter cannot be fixed. But maybe the former?
> 
> Daniel
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:

[Pasi Kärkkäinen]

On Mon, Jul 26, 2010 at 11:36:24AM +0100, Ian Campbell wrote:
> On Sun, 2010-07-25 at 10:27 +0100, Daniel Stodden wrote:
> > On Fri, 2010-07-23 at 03:07 -0400, Keir Fraser wrote:
> > > On 22/07/2010 22:10, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
> > > 
> > > >> You got it right with tap2 (instead of tap). That's the key.
> > > >> 
> > > >> So with Xen 4.0.0 and 2.6.32.14 it's: disk = [
> > > >> 'tap:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
> > > >> 
> > > >> and with Xen 4.0.1-rc4 and 2.6.32.16 it's: disk = [
> > > >> 'tap2:tapdisk:vhd:/mnt/win2008sp2.vhd,xvda:sda1,w' ]
> > > >> 
> > > >> Very subtle change but makes a world of difference. My Windows 2008
> > > >> domU is now booting from a VHD file.
> > > >> 
> > > > 
> > > > Uhm.. is this change intentional?
> > > 
> > > xen-unstable:21338 and xen-4.0-testing:21140. So yes.
> > 
> > That sounds like a lot of fallout on xen-users.
> > Especially for people who just want their guests to boot.
> > 
> > Maybe the whole notation should have rather been some _optional_ blktap
> > = {1|2} cfg key, only for those who actually care?
> 
> FWIW, I completely agree with this.
> 

Yeah, especially when blktap2 is the only available on in pvops dom0 kernels..
All the users have tap:something in their cfgfiles currently..

-- Pasi

> > 
> > [As much as the whole disk notation should probably always just have
> > been <type>:<path>, with a separately configurable <type> -> <backend>
> > mapping for people who want to override backend choices (such
> > file->loopback vs file->aio).]
> > 
> > I guess the latter cannot be fixed. But maybe the former?
> > 
> > Daniel
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:

[Keir Fraser]

On 27/07/2010 07:21, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:

>>> That sounds like a lot of fallout on xen-users.
>>> Especially for people who just want their guests to boot.
>>> 
>>> Maybe the whole notation should have rather been some _optional_ blktap
>>> = {1|2} cfg key, only for those who actually care?
>> 
>> FWIW, I completely agree with this.
>> 
> 
> Yeah, especially when blktap2 is the only available on in pvops dom0 kernels..
> All the users have tap:something in their cfgfiles currently..

Well the patch to make the distinction is currently in xen-unstable and
xen-4.0. Should it be reverted from one or both? Actually it is up to IanJ
or Stefano to decide on that now.

 -- Keir

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:

[Pasi Kärkkäinen]

On Tue, Jul 27, 2010 at 07:48:39AM +0100, Keir Fraser wrote:
> On 27/07/2010 07:21, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
> 
> >>> That sounds like a lot of fallout on xen-users.
> >>> Especially for people who just want their guests to boot.
> >>> 
> >>> Maybe the whole notation should have rather been some _optional_ blktap
> >>> = {1|2} cfg key, only for those who actually care?
> >> 
> >> FWIW, I completely agree with this.
> >> 
> > 
> > Yeah, especially when blktap2 is the only available on in pvops dom0 kernels..
> > All the users have tap:something in their cfgfiles currently..
> 
> Well the patch to make the distinction is currently in xen-unstable and
> xen-4.0. Should it be reverted from one or both? Actually it is up to IanJ
> or Stefano to decide on that now.
> 

Now when Xen 4.0.1-rc5 is out I guess this should be decided shortly..

-- Pasi

Re: tap: vs. tap2: for Xen 4.0.1

[Pasi Kärkkäinen]

On Mon, Aug 02, 2010 at 03:11:52PM +0300, Pasi Kärkkäinen wrote:
> On Tue, Jul 27, 2010 at 07:48:39AM +0100, Keir Fraser wrote:
> > On 27/07/2010 07:21, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:
> > 
> > >>> That sounds like a lot of fallout on xen-users.
> > >>> Especially for people who just want their guests to boot.
> > >>> 
> > >>> Maybe the whole notation should have rather been some _optional_ blktap
> > >>> = {1|2} cfg key, only for those who actually care?
> > >> 
> > >> FWIW, I completely agree with this.
> > >> 
> > > 
> > > Yeah, especially when blktap2 is the only available on in pvops dom0 kernels..
> > > All the users have tap:something in their cfgfiles currently..
> > 
> > Well the patch to make the distinction is currently in xen-unstable and
> > xen-4.0. Should it be reverted from one or both? Actually it is up to IanJ
> > or Stefano to decide on that now.
> > 
> 
> Now when Xen 4.0.1-rc5 is out I guess this should be decided shortly..
> 

Ping?

-- Pasi

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:

[Ian Jackson]

Pasi Kärkkäinen writes ("Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:"):
> On Tue, Jul 27, 2010 at 07:48:39AM +0100, Keir Fraser wrote:
> > Well the patch to make the distinction is currently in xen-unstable and
> > xen-4.0. Should it be reverted from one or both? Actually it is up to IanJ
> > or Stefano to decide on that now.
> 
> Now when Xen 4.0.1-rc5 is out I guess this should be decided shortly..

I think the behaviour should be that you write "tap:" in your file and
get either blktap or blktap2 depend on which is available.  You should
be able to override this with a seperate config option.

(Perhaps this is another thing we need a global xl config file for.)

Ian.

Re: BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:

[Pasi Kärkkäinen]

On Fri, Aug 13, 2010 at 04:18:38PM +0100, Ian Jackson wrote:
> Pasi Kärkkäinen writes ("Re: [Xen-devel] BLKTAPCTRL[2375]: blktapctrl_linux.c:86: blktap0 open failed, tap: vs. tap2:"):
> > On Tue, Jul 27, 2010 at 07:48:39AM +0100, Keir Fraser wrote:
> > > Well the patch to make the distinction is currently in xen-unstable and
> > > xen-4.0. Should it be reverted from one or both? Actually it is up to IanJ
> > > or Stefano to decide on that now.
> > 
> > Now when Xen 4.0.1-rc5 is out I guess this should be decided shortly..
> 
> I think the behaviour should be that you write "tap:" in your file and
> get either blktap or blktap2 depend on which is available.  You should
> be able to override this with a seperate config option.
> 

Yeah, this sounds good to me.

I've updated http://wiki.xensource.com/xenwiki/blktap2 wiki page
to reflect the Xen 4.0.1 current state, aka you need tap2: there..

-- Pasi