WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

[Xen-users] block-* scripts multiple issues

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] block-* scripts multiple issues
From: Zakk <zakk@xxxxxxxxx>
Date: Wed, 5 Mar 2008 11:39:35 -0500
Delivery-date: Tue, 11 Mar 2008 10:30:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Greetings,

Let me preface this by saying I'm currently running Xen 3.2.0 under CentOS 5.1, although I believe these issues were present in 3.1.x also.


I'm experimenting with a setup that uses the block-drbd disk script provided by the drbd team. I've come across multiple problems, some of which I believe would apply to any other block-* script...


1) The xm python libs (specifically the code path for 'create') sanity check the VBD to make sure it's accessible. This is especially a problem with the drbd type since the 'device' specification is just a label, so xm create has no idea how to find the real device. This I can work around with a quick patch that calls the drbdadm tool and gets the actual device name.

2) If you're using pygrub, it is executed before any of the block scripts; so if there's any setup that needs to occur before the VBD is accessible, pygrub will fail. Again, this is the case with drbd because it won't let you much around in the device if you haven't become 'primary'. However, fixable with a workaround where you specify an alternate bootloader that's just a wrapper around pygrub that does whatever magic you need.


And here's the one I can't work around...


3) If you use qemu-dm as the device model, it is started before the block scripts are run. So just like pygrub, it fails to access the VBD in some instances and then the VBD isn't there in your domU. Which usually breaks your domU. This one I can't just simply put a wrapper around since the VBD isn't passed in on the command line.


It seems to me like it may make some sense to have an interface into the block scripts so xm create can say 'I need your real device name, and do any setup needed assuming you're about to become active'. This would solve all three of the issues I listed, with a bit of added complication of how to pass the correct device name to qemu-dm. However, I don't know the code well enough to know how the case of live migration/qemu-dm/block-* works and what (if anything) needs to be done there. I plan on testing that next.

Any ideas as to a reasonable solution to this stuff?

Thanks, and sorry about the length.

-=Zakk




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

<Prev in Thread] Current Thread [Next in Thread>