xen-devel
Re: [Xen-devel] CS 21556 (blktap2: Fix tapdisk disktype issues) is no lo
1. [PATCH] blktap2: blktap2 and pygrub (xen-unstable)
diff -r a672af698bc3 tools/python/xen/xend/XendDomainInfo.py --- a/tools/python/xen/xend/XendDomainInfo.py Fri Jul 09 12:35:58 2010 +0100 +++ b/tools/python/xen/xend/XendDomainInfo.py Sun Jul 11 17:16:39 2010 +0400 @@ -3261,6 +3261,7 @@ taptype = blkdev_uname_to_taptype(disk) mounted = devtype in ['tap', 'tap2'] and taptype != 'aio' and taptype != 'sync' and not os.stat(fn).st_rdev + mounted_vbd_uuid = 0 if mounted: # This is a file, not a
device. pygrub can cope with a # file if it's raw, but if it's QCOW or other such formats @@ -3276,7 +3277,8 @@ from xen.xend import XendDomain dom0 = XendDomain.instance().privilegedDomain() - dom0._waitForDeviceUUID(dom0.create_vbd(vbd, disk)) + mounted_vbd_uuid = dom0.create_vbd(vbd, disk); +
dom0._waitForDeviceUUID(mounted_vbd_uuid) fn = BOOTLOADER_LOOPBACK_DEVICE try: @@ -3286,8 +3288,9 @@ if mounted: log.info("Unmounting %s from %s." % (fn, BOOTLOADER_LOOPBACK_DEVICE)) - - dom0.destroyDevice('tap',
BOOTLOADER_LOOPBACK_DEVICE) + _, vbd_info = dom0.info['devices'][mounted_vbd_uuid] + dom0.destroyDevice(dom0.getBlockDeviceClass(vbd_info['devid']), + BOOTLOADER_LOOPBACK_DEVICE, force = True) if blcfg is None: msg = "Had a bootloader specified, but can't find disk"
2. [PATCH] blktap/blktap2: Fix for
incorrect parse disk configuration (xen-unstable)
diff -r a672af698bc3 tools/python/xen/util/blkif.py --- a/tools/python/xen/util/blkif.py Fri Jul 09 12:35:58 2010 +0100 +++ b/tools/python/xen/util/blkif.py Sun Jul 11 12:13:34 2010 +0400 @@ -87,7 +87,10 @@ fn = "/dev/%s" %(fn,) if typ in ("tap", "tap2"): - (taptype, fn) = fn.split(":", 1) + if fn.count(":") == 1: + (taptype, fn) = fn.split(":",
1) + else: + (taptype, fn) = fn.split(":", 2)[1:3] return (fn, taptype) def blkdev_uname_to_file(uname):
I've tested this patches. They make things working for NexexentaStor 3.0.2 xen image with "vhd" files and pygrub as bootloader at Xen 4.1-unstable ( tip CS) & 2.6.32.16 Dom0 on top of Ubuntu 10.04 Server.
Per exeCooler :-
process of booting DomU with 'mounted-blktap2' (VHD for example) and 'pygrub' as bootloader:
1. Connect boot-device to Dom0 as '/dev/xpvd' 2. Pygrub get info for load DomU 3. Disconnect boot-device from Dom0 4. Boot DomU
During step 3 created device disconnecting from Dom0, but xenstore does not scrape away after device disconnected from Dom0 => result:
"Error: Device /dev/xvdp (51952, tap2) is already connected."
During step 3 created device disconnecting from Dom0, but 'destroyDevice' method is passed 'tap' always => result: "Error: Device 51952 not connected"
Boris. P.S. It's just a reminder of content been already posted by exeCooler to xen-devel mailing list.
--- On Mon, 7/12/10, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> Subject: Re: [Xen-devel] CS 21556 (blktap2: Fix tapdisk disktype issues) is no longer working for "vhd" [and 1 more messages] To: "eXeC001er" <execooler@xxxxxxxxx> Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Boris Derzhavets" <bderzhavets@xxxxxxxxx>, "Keir Fraser"
<keir.fraser@xxxxxxxxxxxxx> Date: Monday, July 12, 2010, 1:01 PM
Boris Derzhavets writes ("[Xen-devel] CS 21556 (blktap2: Fix tapdisk disktype issues) is no longer working for "vhd""): > In about the most recent 4-5 days an error :
This is related to 21541:7ff0e885b5c3 and 21728:51160a8ecf7d.
> root@ServerLSX:~/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: [Errno 2] No such file or directory: 'vhd:/root/NexentaStor-Community-3.0.2/syspool.img' > > has been brought back under xen-unstable.
Does this work in 4.0-testing ?
eXeC001er writes ("[Xen-devel] Re: CS 21556 (blktap2: Fix tapdisk disktype issues) is no longer working for "vhd""): > My patch was not quite correct. I waited until the return change back to > make a new one. > The new
patch will be ready today or tomorrow. Let's see how will the > situation was.
Thanks. As I wrote earlier:
Can I ask you to try to (a) separate out these patches, and (b) explain the reasoning behind them in more detail ? If you can provide a separate message with a separate patch for each change, with an explanation at greater length, it will be much easier for us to evaluate them. Thanks.
Thanks, Ian.
|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|