Re: [Xen-devel] [PATCH] Re: blktap2 problem with pvops kernel 2.6.32.13 and xen 4.0-rc1

[eXeC001er <execooler@xxxxxxxxx>]

2010/6/1 Boris Derzhavets <bderzhavets@xxxxxxxxx>

The way your patch + zfs-24 patch work for me ( Nexenta 3.0 Xen Sample Image and profile)

root@LucidSRV:~/NexentaStor-Community-3.0.2# cat *.cfg
# This config file use for boot installation guest domain NexentaStor, hereinafter referred to as DomU

# Work directory
# work_dir = '/full/path/to/directory/with/unpacked/nexentastor-xen-image'
work_dir = '/root/NexentaStor-Community-3.0.2'

# Names of disks
disk_1_name = 'syspool.img'
disk_2_name = 'data_disk1.img'
disk_3_name = 'data_disk2.img'
disk_4_name = 'data_disk3.img'

# Bootloader for boot DomU
bootloader = "/usr/local/bin/pygrub"

# Memory for DomU, in MB
memory = 1024

# Name of DomU
name = "NexentaStor-Community-3.0.2"

# Network interfaces for DomU
# You can change the mac address of your own needs.
# mac=00:16:3E:xx:xx:xx
Âvif = ÂÂÂ [
ÂÂÂ 'mac=00:16:3E:00:00:01',
Â'mac=00:16:3E:00:00:02'
ÂÂÂ ]
# vif=['bridge=eth0']

# Disk's for guest domain.
# Format for added disk:
# for file devices disk:
# ÂÂÂ 'file:/full/path/to/disk_in_file,num_disk_in_DomU,access_mode_for_disk_in_DomU'
# for tap device disk (for example VHD):
#ÂÂÂ 'tap:tapdisk:vhd:/full/path/to/disk_in_file,num_disk_in_DomU,access_mode_for_disk_in_DomU'
# for physical devices disk:
#ÂÂÂ 'phy:/dev/physical_devices_in_Dom0,num_disk_in_DomU,access_mode_for_disk_in_DomU'
# num_disk_in_DomU = xvda,xvdb,xvdc,xvde,...
# access_mode_for_disk_in_DomU = w - read-write mode, r = read-only mode
#
# We recommend using the VHD disc format (blktap2 device driver).
# http://wiki.xensource.com/xenwiki/blktap2
disk = ÂÂÂ [
ÂÂÂ 'tap:tapdisk:vhd:' + work_dir + '/' + disk_1_name + ',xvda,w',
ÂÂÂ 'tap:tapdisk:vhd:' + work_dir + '/' + disk_2_name + ',xvdb,w',
ÂÂÂ 'tap:tapdisk:vhd:' + work_dir + '/' + disk_3_name + ',xvdc,w',
ÂÂÂ 'tap:tapdisk:vhd:' + work_dir + '/' + disk_4_name + ',xvde,w',
ÂÂÂ ]

# 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.
>>>

root@LucidSRV:~/NexentaStor-Community-3.0.2# xm create -c nexentastor-community-3.0.2-xen.cfg
Using config file "./nexentastor-community-3.0.2-xen.cfg".

root@LucidSRV:~/NexentaStor-Community-3.0.2# Error: Device 51952 not connected
^C

I found error in this configuration. need to replase tap >>> tap2. sorry for mistake.Â

root@LucidSRV:~/NexentaStor-Community-3.0.2# xm list
NameÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ IDÂÂ Mem VCPUsÂÂÂÂÂ StateÂÂ Time(s)
Domain-0ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ 0Â 7189ÂÂÂÂ 4ÂÂÂÂ r-----ÂÂÂÂ 38.1

root@LucidSRV:~/NexentaStor-Community-3.0.2# xm create -c nexentastor-community-3.0.2-xen.cfg
Using config file "./nexentastor-community-3.0.2-xen.cfg".
Error: Device /dev/xvdp (51952, tap2) is already connected.

I found a solution to the problem, not sure that it is 100% correct solution, but it works for me. I will research and debug this issue.

workaround:Â

stop blktap2_mount: echo 1 >Â/sys/class/blktap2/blktapX/remove

remove record from xenstore:Â

xenstore-rm /vm/00000000-0000-0000-0000-000000000000

Boris
--- On Mon, 5/31/10, eXeC001er <execooler@xxxxxxxxx> wrote:

From: eXeC001er <execooler@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Re: blktap2 problem with pvops kernel 2.6.32.13 and xen 4.0-rc1
To: "Boris Derzhavets" <bderzhavets@xxxxxxxxx>
Cc: "Xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>

Date: Monday, May 31, 2010, 12:28 PM

I have same error with xen-unstable.

in attach patch forÂxen-4.0-testing.hg

Signed-off-by: eXeC001er <execooler@xxxxxxxxx>
---

2010/5/31 Boris Derzhavets <bderzhavets@xxxxxxxxx>

ÂXen-unstable patched via yours patch , built and installed on top of Ubuntu 10.04.
ÂDom0 loaded with 2.6.32.14 pvops ( 2.6.32.10 same results)
ÂEnvironment:-

hostÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ : LucidSRV
releaseÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ : 2.6.32.14
versionÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ : #6 SMP Mon May 31 18:08:00 MSD 2010
machineÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ : x86_64
nr_cpusÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ : 4
nr_nodesÂÂÂÂÂÂÂÂÂÂÂÂÂÂ : 1
cores_per_socketÂÂÂÂÂÂ : 4
threads_per_coreÂÂÂÂÂÂ : 1
cpu_mhzÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ : 2833
hw_capsÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ : bfebfbff:20100800:00000000:00000940:0408e3fd:00000000:00000001:00000000
virt_capsÂÂÂÂÂÂÂÂÂÂÂÂÂ : hvm
total_memoryÂÂÂÂÂÂÂÂÂÂ : 8190
free_memoryÂÂÂÂÂÂÂÂÂÂÂ : 2052
free_cpusÂÂÂÂÂÂÂÂÂÂÂÂÂ : 0
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
xen_schedulerÂÂÂÂÂÂÂÂÂ : credit
xen_pagesizeÂÂÂÂÂÂÂÂÂÂ : 4096
platform_paramsÂÂÂÂÂÂÂ : virt_start=0xffff800000000000
xen_changesetÂÂÂÂÂÂÂÂÂ : Fri May 28 10:54:07 2010 +0100 21492:96917cf25bf3
xen_commandlineÂÂÂÂÂÂÂ :
cc_compilerÂÂÂÂÂÂÂÂÂÂÂ : gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
cc_compile_byÂÂÂÂÂÂÂÂÂ : root
cc_compile_domainÂÂÂÂÂ :
cc_compile_dateÂÂÂÂÂÂÂ : Mon May 31 19:00:21 MSD 2010
xend_config_formatÂÂÂÂ : 4

ÂAttempted to load F13 PV DomU ( working fine inder Xen 4.0 & 2.6.32.14)


ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
Ââ Fedora (2.6.33.3-85.fc13.x86_64)ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ â
Ââ â
Ââ â
Ââ â
Ââ â
Ââ â
Ââ â
Ââ â
Âââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
ÂÂÂÂ Use the ^ and v keys to select which entry is highlighted.
ÂÂÂÂ Press enter to boot the selected OS, 'e' to edit the
ÂÂÂÂ commands before booting, 'a' to modify the kernel arguments
ÂÂÂÂ before booting, or 'c' for a command line.

root@LucidSRV:/home/boris/fedora# Error: (4, 'Out of memory', "panic: xc_dom_boot.c:144: xc_dom_boot_mem_init: can't allocate low memory for domain")


Boris.

--- On Mon, 5/31/10, eXeC001er <execooler@xxxxxxxxx> wrote:

From: eXeC001er <execooler@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Re: blktap2 problem with pvops kernel 2.6.32.13 and xen 4.0-rc1

To: "Boris Derzhavets" <bderzhavets@xxxxxxxxx>
Cc: "Xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Date: Monday, May 31, 2010, 6:27 AM

Patch for xen-unstable.hg

2010/5/31 Boris Derzhavets <bderzhavets@xxxxxxxxx>

I've attempted to process patch for xen-4.0.0-0.7.f12.src.rpm it gives an errors.
Is it written for xen 4.0 ? I did some manual check .

Boris.


--- On Sun, 5/30/10, eXeC001er <execooler@xxxxxxxxx> wrote:

From: eXeC001er <execooler@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Re: blktap2 problem with pvops kernel 2.6.32.13 and xen 4.0-rc1
To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Cc: "Boris Derzhavets" <bderzhavets@xxxxxxxxx>, "Xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Date: Sunday, May 30, 2010, 11:00 AM

this patch remove problems with blktap2 devices:

1. If we use blktap2 disk device then DomU does not boot. Returned error:ÂFile 'vhd:/path/.../disk.img' doesn't exist.

2. Created blktap2 disk device does not accessibleÂimmediately after connecting: If we use pygrub then DomU does not boot. Returned error: Disk is not accessible.

Signed-off-by: eXeC001er <execooler@xxxxxxxxx>
---

2010/5/30 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>

Needs a patch description and a signed-off-by line.

Â-- Keir

On 30/05/2010 13:21, "eXeC001er" <execooler@xxxxxxxxx> wrote:

> My python-experienceÂis small, but i tied to rewrite.
> New in attach.
>
> 2010/5/30 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
>> On 30/05/2010 11:37, "Pasi KÃrkkÃinen" <pasik@xxxxxx> wrote:
>>
>>> On Sun, May 30, 2010 at 02:02:06PM +0400, eXeC001er wrote:
>>>> Â ÂI have already sent a patch 1 weak ago. (blktap2_control_func.patch)
>>>> Â Ârepeat in attach.
>>>> Â ÂThanks.
>>>
>>> Ok, thanks.
>>>
>>> Keir: I guess this is not committed yet?
>>
>> I'm not too happy about the sleep(5). I guess if there's no better solution
>> coming up I should just whack this patch in?
>>
>> Â-- Keir
>>
>>> -- Pasi
>>>
>>>> Â Â2010/5/30 Pasi KÃrkkÃinen <[1]pasik@xxxxxx>
>>>>
>>>> Â Â ÂOn Sun, May 30, 2010 at 11:17:51AM +0400, eXeC001er wrote:
>>>>> Â Â ÂI've attempted to install Nexenta Core 3 image under Xen 4.0
>>>> Â Â Â(2.6.32.13
>>>>> Â Â Âpvops) on top of F13. Sample nexenta3.cfg profile contains 4
>>>> Â Â Âlines like
>>>>> Â Â Âthis:-
>>>>>
>>>>> Â Â Âdisk=['tat:tapdisk:vhd:/path/../disk.img,xvda,w'] ( from sample)
>>>>>
>>>>> Â Â ÂIt generates message
>>>>> Â Â ÂÃ File 'vhd:/path/.../disk.img' doesn't exist.
>>>>>
>>>>> Â Â ÂBoris.
>>>>> Â Â ÂP.S. It was already in one of the threads @xen-users.
>>>>>
>>>>> Â ÂThis bug in "def _parse_uname(uname):"
>>>> Â Â Â(tools/python/xen/util/blkif.py)
>>>>> Â Â(taptype, fn) = fn.split(":", 1) >>>>>>Ã (taptype, fn) =
>>>> Â Â Âfn.split(":",
>>>>> Â Â2)[1:3]
>>>>
>>>> Â Â ÂCan you send a proper patch, as unified diff (diff -u), with a
>>>> Â Â ÂSigned-off-by line?
>>>> Â Â Â-- Pasi
>>>>
>>>> References
>>>>
>>>> Â ÂVisible links
>>>> Â Â1. mailto:pasik@xxxxxx
>>>
>>>> diff -r d0420ab97345 tools/python/xen/util/blkif.py
>>>> --- a/tools/python/xen/util/blkif.py Fri May 21 16:21:39 2010 +0100
>>>> +++ b/tools/python/xen/util/blkif.py Sat May 22 01:21:15 2010 +0400
>>>> @@ -87,7 +87,7 @@
>>>> Â Â Â Â Â Â Â Â Âfn = "/dev/%s" %(fn,)
>>>>
>>>> Â Â Â Â Âif typ in ("tap", "tap2"):
>>>> - Â Â Â Â Â Â(taptype, fn) = fn.split(":", 1)
>>>> + Â Â Â Â Â Â(taptype, fn) = fn.split(":", 2)[1:]
>>>> Â Â Âreturn (fn, taptype)
>>>>
>>>> Âdef blkdev_uname_to_file(uname):
>>>> diff -r d0420ab97345 tools/python/xen/xend/XendDomainInfo.py
>>>> --- a/tools/python/xen/xend/XendDomainInfo.py Fri May 21 16:21:39 2010
>>>> +0100
>>>> +++ b/tools/python/xen/xend/XendDomainInfo.py Sat May 22 01:21:15 2010
>>>> +0400
>>>> @@ -3292,6 +3292,7 @@
>>>> Â Â Â Â Â Â Â Â Âfn = BOOTLOADER_LOOPBACK_DEVICE
>>>>
>>>> Â Â Â Â Â Â Âtry:
>>>> + Â Â Â Â Â Â Â Âtime.sleep(5)
>>>> Â Â Â Â Â Â Â Â Âblcfg = bootloader(blexec, fn, self, False,
>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â bootloader_args, kernel, ramdisk, args)
>>>> Â Â Â Â Â Â Âfinally:
>>>> @@ -3299,7 +3300,7 @@

>>>> Â Â Â Â Â Â Â Â Â Â Âlog.info <http://log.info> ("Unmounting %s from %s." %

>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (fn, BOOTLOADER_LOOPBACK_DEVICE))
>>>>
>>>> - Â Â Â Â Â Â Â Â Â Âdom0.destroyDevice('tap', BOOTLOADER_LOOPBACK_DEVICE)
>>>> + Â Â Â Â Â Â Â Â Â Âdom0.destroyDevice(devtype,
>>>> BOOTLOADER_LOOPBACK_DEVICE)
>>>>
>>>> Â Â Â Â Â Â Âif blcfg is None:
>>>> Â Â Â Â Â Â Â Â Âmsg = "Had a bootloader specified, but can't find disk"
>>>
>>
>>
>
>

-----Inline Attachment Follows-----

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

-----Inline Attachment Follows-----

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

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