Hi, For domain migration, unless you use a rootless setup, you need to have network storage available. For the poor people like me that dave no SAN, one easy possibility to have it is to use nbd. Find attached the block-nbd script (in /etc/xen/scripts/) and an example config file. The block-nbd script is based on the -enbd one. They have been used successfully in the Xen Tutorial at Linux Kongress. I would appreciate to see these integrated. Signed-off-by: Kurt Garloff <garloff@suse.de> -- Kurt Garloff, Director SUSE Labs, Novell Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Find attached the block-nbd script (in /etc/xen/scripts/) and > an example config file. The block-nbd script is based on the > -enbd one. > They have been used successfully in the Xen Tutorial at Linux > Kongress.disk = [ ''nbd:134.100.233.115 20004,hda1,w'' ] I think having the space in the export device name is just a little too nauseating :-) Could we make the script take ip:port and then turn the '':'' into a space when invoking nbdclient? On this subject, I think it would be less confusing if we configured disks using a syntax more akin to that which we use for networking e.g.: disks = [ ''export=phy:/dev/sda1, target=/dev/sda1, options=rw'', ''export=phy:/dev/vg/my_usr, target=/dev/sdb1, options=ro'' ] I know its late in the day to be making changes like this, but it doesn''t hurt to canvass opinion... I''d also do away with all the fancy stuff we have to build the command line and just have a single command line variable that we assemble everything in to within the config file. The current magic just makes things more confusing. Ian Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:>disk = [ ''nbd:134.100.233.115 20004,hda1,w'' ] > >I think having the space in the export device name is just a little too >nauseating :-) > >Could we make the script take ip:port and then turn the '':'' into a space >when invoking nbdclient? > >On this subject, I think it would be less confusing if we configured >disks using a syntax more akin to that which we use for networking e.g.: > >I actually like this idea a lot. I''m not a huge fan of the current block device configuration.>disks = [ ''export=phy:/dev/sda1, target=/dev/sda1, options=rw'', > ''export=phy:/dev/vg/my_usr, target=/dev/sdb1, options=ro'' ] > >I know its late in the day to be making changes like this, but it >doesn''t hurt to canvass opinion... > >The only thing to think about is how do handle file devices with spaces in the filename. This is going to be common I think. Comma and spaces are valid filename characters. I think : is probably the safest separator since it''s used a lot.>I''d also do away with all the fancy stuff we have to build the command >line and just have a single command line variable that we assemble >everything in to within the config file. The current magic just makes >things more confusing. > >Yes :-) Regards, Anthony Liguori>Ian > > > > > >Ian > > >_______________________________________________ >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
Nivedita Singhvi
2005-Oct-19 22:12 UTC
Re: [Xen-devel] block-nbd script and example config
Ian Pratt wrote:>>Find attached the block-nbd script (in /etc/xen/scripts/) and >>an example config file. The block-nbd script is based on the >>-enbd one. >>They have been used successfully in the Xen Tutorial at Linux >>Kongress. > > > disk = [ ''nbd:134.100.233.115 20004,hda1,w'' ] > > I think having the space in the export device name is just a little too > nauseating :-) > > Could we make the script take ip:port and then turn the '':'' into a space > when invoking nbdclient? > > On this subject, I think it would be less confusing if we configured > disks using a syntax more akin to that which we use for networking e.g.: > > disks = [ ''export=phy:/dev/sda1, target=/dev/sda1, options=rw'', > ''export=phy:/dev/vg/my_usr, target=/dev/sdb1, options=ro'' ] > > I know its late in the day to be making changes like this, but it > doesn''t hurt to canvass opinion...Great idea, I think it will be much cleaner and reduce the inevitable configuration errors.. thanks, Nivedita> I''d also do away with all the fancy stuff we have to build the command > line and just have a single command line variable that we assemble > everything in to within the config file. The current magic just makes > things more confusing. > > > Ian > > > > > > Ian > > > _______________________________________________ > 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
On 10/20/05, Anthony Liguori <aliguori@us.ibm.com> wrote:> >disks = [ ''export=phy:/dev/sda1, target=/dev/sda1, options=rw'', > > ''export=phy:/dev/vg/my_usr, target=/dev/sdb1, options=ro'' ]> The only thing to think about is how do handle file devices with spaces > in the filename. This is going to be common I think.Since it''s a python variable can''t you just run a validator on config import and throw an exception if the devive block doesn''t exist. Noting that device paths including special characters need to be enclosured in "...". ie. export=phy:"/dev/vgname/bob your uncle; mate! device", ... -- Nicholas Lee http://stateless.geek.nz gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Nicholas Lee wrote:>>The only thing to think about is how do handle file devices with spaces >>in the filename. This is going to be common I think. >> >> > >Since it''s a python variable can''t you just run a validator on config >import and throw an exception if the devive block doesn''t exist. >Noting that device paths including special characters need to be >enclosured in "...". > >ie. export=phy:"/dev/vgname/bob your uncle; mate! device", ... > >Double quotes are actually valid characters in a filename although rarely used. A more bold way of approaching this would be to adopt a more qemu like syntax of: hda1="/dev/vgname/bob you uncle; mate1" hda2="/root/rockhopper.img" We could use stat to figure out whether something was a file or a device and use the appropriate script (file or phy). For everything else, we could use explicit urls such as: hda3="nbd://rockhopper.austin.ibm.com:1025" I like the syntax a lot but I''m not sure that marking a device read-only works nicely anymore. We could have a single readonly attribute like: readonly=[''hda1'', ''hda2''] Or perhaps just require url encoding: hda1="phy:///dev/vgname/bob you uncle&readonly=1" Kind of ugly but at least we''re optimizing for the common case. Just thinking out loud. Regards, Anthony Liguori>-- >Nicholas Lee >http://stateless.geek.nz >gpg 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anthony Liguori wrote:> Nicholas Lee wrote: > >>> The only thing to think about is how do handle file devices with spaces >>> in the filename. This is going to be common I think. >>> >> >> Since it''s a python variable can''t you just run a validator on config >> import and throw an exception if the devive block doesn''t exist. >> Noting that device paths including special characters need to be >> enclosured in "...". >> >> ie. export=phy:"/dev/vgname/bob your uncle; mate! device", ... >> >> > Double quotes are actually valid characters in a filename although > rarely used. > > A more bold way of approaching this would be to adopt a more qemu like > syntax of: > > hda1="/dev/vgname/bob you uncle; mate1" > hda2="/root/rockhopper.img" > > We could use stat to figure out whether something was a file or a > device and use the appropriate script (file or phy). For everything > else, we could use explicit urls such as: > > hda3="nbd://rockhopper.austin.ibm.com:1025" > > I like the syntax a lot but I''m not sure that marking a device > read-only works nicely anymore. We could have a single readonly > attribute like: > > readonly=[''hda1'', ''hda2'']For readonly i would suggest a kind of following syntax: hda1:r="/dev/..." hda2:w="/dev/.." Arnd ___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> >On this subject, I think it would be less confusing if we configured > >disks using a syntax more akin to that which we use for > networking e.g.: > > > > > I actually like this idea a lot. I''m not a huge fan of the > current block device configuration. > > >disks = [ ''export=phy:/dev/sda1, target=/dev/sda1, options=rw'', > > ''export=phy:/dev/vg/my_usr, target=/dev/sdb1, options=ro'' ] > > > >I know its late in the day to be making changes like this, but it > >doesn''t hurt to canvass opinion... > > > The only thing to think about is how do handle file devices > with spaces in the filename. This is going to be common I think. > > Comma and spaces are valid filename characters. I think : is > probably the safest separator since it''s used a lot.Let''s think a little about what we''d like this to look like. Taking a similar approach to network devices, we''d end up with something that looks like this: disks = [ ''export=phy:/dev/sda1, target=/dev/sda1, options=rw'', ''export=phy:/dev/vg/my_usr, target=/dev/sdb1, options=ro'' ] I''m wandering whether the following although slightly ugly might be better from a python POV (we''d change network devices acordingly too: disks = [ { ''export'':''phy:/dev/sda1'', ''target'':''/dev/sda1'', ''options'':''rw'' }, { ''export'':''phy:/dev/vg/my_usr'', ''target'':''/dev/sdb1'', ''options'':''ro'' } ] Is this just too ugly and would we be better off going with my first proposal? Or should we just leave things alone for 3.0? Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Oct 19, 2005 at 12:09:51PM +0200, Kurt Garloff wrote:> Hi, > > For domain migration, unless you use a rootless setup, you need > to have network storage available. For the poor people like me that > dave no SAN, one easy possibility to have it is to use nbd. > > Find attached the block-nbd script (in /etc/xen/scripts/) and > an example config file. The block-nbd script is based on the -enbd one. > They have been used successfully in the Xen Tutorial at Linux Kongress. > > I would appreciate to see these integrated. > > Signed-off-by: Kurt Garloff <garloff@suse.de>Thanks Kurt -- I''ve commited these. I renamed xen-nbd to xmexample.nbd, for consistency with the other xm create example configurations. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > Find attached the block-nbd script (in /etc/xen/scripts/) and an > > example config file. The block-nbd script is based on the -enbd one. > > They have been used successfully in the Xen Tutorial at > Linux Kongress. > > > > I would appreciate to see these integrated. > > > > Signed-off-by: Kurt Garloff <garloff@suse.de> > > Thanks Kurt -- I''ve commited these. I renamed xen-nbd to > xmexample.nbd, for consistency with the other xm create > example configurations.I still think we should '':'' rather than space as the delimiter between host and port, and have the script split out the args to nbdclient. Having spaces in the device name is too ugly... Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Pratt wrote:>Let''s think a little about what we''d like this to look like. > >Taking a similar approach to network devices, we''d end up with something >that looks like this: > > disks = [ ''export=phy:/dev/sda1, target=/dev/sda1, options=rw'', > ''export=phy:/dev/vg/my_usr, target=/dev/sdb1, options=ro'' ] > >Yup. Here''s another example: disks = [ ''export=file:/home/anthony/images/Fedora Core 4.img, target=/dev/sda1, options=rw'', This is going to become difficult to parse (we could split with '','' here but then what if we have commas in files). We could support an escaping mechanism but then it would require triple escapes like: disks = [ ''export=file:/home/anthony/image/Fedora Core 4\\\, x86-64.img, target=/dev/sda1, options=rw'' ] Or regular expression syntax: disks = [ r''export=file:/home/anthony/image/Fedora Core 4\, x86-64.img, target=/dev/sda1, options=rw'' ]>I''m wandering whether the following although slightly ugly might be >better from a python POV (we''d change network devices acordingly too: > > disks = [ { ''export'':''phy:/dev/sda1'', ''target'':''/dev/sda1'', >''options'':''rw'' }, > { ''export'':''phy:/dev/vg/my_usr'', ''target'':''/dev/sdb1'', >''options'':''ro'' } ] > >I thought of this too. I think it''s just too much to ask from users though. If you know python, it''s understandable, but if you don''t, I think it reads like gibberish.>Is this just too ugly and would we be better off going with my first >proposal? Or should we just leave things alone for 3.0? > >Yeah, perhaps we should just leave things alone for 3.0. We can revisit when someone comes up with a clever syntax that solves the above problems. Regards, Anthony Liguori>Ian > > > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Yup. Here''s another example: > > disks = [ ''export=file:/home/anthony/images/Fedora Core > 4.img, target=/dev/sda1, options=rw'', > > This is going to become difficult to parse (we could split > with '','' here but then what if we have commas in files). We > could support an escaping mechanism but then it would require > triple escapes like: > > disks = [ ''export=file:/home/anthony/image/Fedora Core 4\\\, > x86-64.img, target=/dev/sda1, options=rw'' ]The best way of doing this is: disks = [ ''export=file:"/home/anthony/images/Fedora Core 4.img", target=/dev/sda1, options=rw'', We''d remove double quotes and treat anything between them as a single token. I think this would work OK. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel