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

[eXeC001er <execooler@gmail.com>]

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

2010/6/1 Boris Derzhavets <bderzhavets@yahoo.com>

> 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.
> on_reboot = 'destroy'
> on_crash = 'destroy'
> on_poweroff = 'destroy'
>
>
> 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@gmail.com>* wrote:
>
>
> From: eXeC001er <execooler@gmail.com>
> Subject: Re: [Xen-devel] [PATCH] Re: blktap2 problem with pvops kernel
> 2.6.32.13 and xen 4.0-rc1
> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Cc: "Xen-devel" <xen-devel@lists.xensource.com>, "Keir Fraser" <
> keir.fraser@eu.citrix.com>
> 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@gmail.com<http://mc/compose?to=execooler@gmail.com>
> >
> ---
>
> 2010/5/31 Boris Derzhavets <bderzhavets@yahoo.com<http://mc/compose?to=bderzhavets@yahoo.com>
> >
>
>>  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@gmail.com<http://mc/compose?to=execooler@gmail.com>
>> >* wrote:
>>
>>
>> From: eXeC001er <execooler@gmail.com<http://mc/compose?to=execooler@gmail.com>
>> >
>> Subject: Re: [Xen-devel] [PATCH] Re: blktap2 problem with pvops kernel
>> 2.6.32.13 and xen 4.0-rc1
>> To: "Boris Derzhavets" <bderzhavets@yahoo.com<http://mc/compose?to=bderzhavets@yahoo.com>
>> >
>> Cc: "Xen-devel" <xen-devel@lists.xensource.com<http://mc/compose?to=xen-devel@lists.xensource.com>>,
>> "Keir Fraser" <keir.fraser@eu.citrix.com<http://mc/compose?to=keir.fraser@eu.citrix.com>
>> >
>> Date: Monday, May 31, 2010, 6:27 AM
>>
>>
>> Patch for xen-unstable.hg
>>
>> 2010/5/31 Boris Derzhavets <bderzhavets@yahoo.com<http://mc/compose?to=bderzhavets@yahoo.com>
>> >
>>
>>> 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@gmail.com<http://mc/compose?to=execooler@gmail.com>
>>> >* wrote:
>>>
>>>
>>> From: eXeC001er <execooler@gmail.com<http://mc/compose?to=execooler@gmail.com>
>>> >
>>> 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@eu.citrix.com<http://mc/compose?to=keir.fraser@eu.citrix.com>
>>> >
>>> Cc: "Boris Derzhavets" <bderzhavets@yahoo.com<http://mc/compose?to=bderzhavets@yahoo.com>>,
>>> "Xen-devel" <xen-devel@lists.xensource.com<http://mc/compose?to=xen-devel@lists.xensource.com>
>>> >
>>> 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@gmail.com<http://mc/compose?to=execooler@gmail.com>
>>> >
>>> ---
>>>
>>>  2010/5/30 Keir Fraser <keir.fraser@eu.citrix.com<http://mc/compose?to=keir.fraser@eu.citrix.com>
>>> >
>>>
>>>> Needs a patch description and a signed-off-by line.
>>>>
>>>>  -- Keir
>>>>
>>>> On 30/05/2010 13:21, "eXeC001er" <execooler@gmail.com<http://mc/compose?to=execooler@gmail.com>>
>>>> wrote:
>>>>
>>>> > My python-experience is small, but i tied to rewrite.
>>>> > New in attach.
>>>> >
>>>> > 2010/5/30 Keir Fraser <keir.fraser@eu.citrix.com<http://mc/compose?to=keir.fraser@eu.citrix.com>
>>>> >
>>>> >> On 30/05/2010 11:37, "Pasi Kärkkäinen" <pasik@iki.fi<http://mc/compose?to=pasik@iki.fi>>
>>>> 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@iki.fi<http://mc/compose?to=pasik@iki.fi>
>>>> >
>>>> >>>>
>>>> >>>>      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@iki.fi <http://mc/compose?to=pasik@iki.fi>
>>>> >>>
>>>> >>>> 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@lists.xensource.com<http://mc/compose?to=Xen-devel@lists.xensource.com>
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>>
>>
>> -----Inline Attachment Follows-----
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com<http://mc/compose?to=Xen-devel@lists.xensource.com>
>> http://lists.xensource.com/xen-devel
>>
>>
>>
>
>

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

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

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