| Message ID | 1341313544-6256-1-git-send-email-xiawenc@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
> + > + Note: When qemu-nbd was used to export a disk that would be used by QEMU > +block device, -t or --persistent must be set for that QEMU nbd client would try > +connect more than one time. For eg: ^^^^^^ Not a native english speaker, but I never see such usage before. Should be "For example"? Regards, chenwj
On 03.07.2012 15:05, xiawenc@linux.vnet.ibm.com wrote: > From: Wenchao Xia <xiawenc@linux.vnet.ibm.com> > > Qemu system emulator reports only fails that make people confused > about why, when it is invoked with nbd block device tring to connect > qemu-nbd server. In fact qemu will try connect server for several > times but server only accept one connect by default. > I paid some times to find out why it fails. This patch add special > text to explain how to use it in such case. > > Signed-off-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com> > --- > qemu-nbd.texi | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/qemu-nbd.texi b/qemu-nbd.texi > index 6955d90..014040a 100644 > --- a/qemu-nbd.texi > +++ b/qemu-nbd.texi > @@ -44,6 +44,12 @@ Export QEMU disk image using NBD protocol. > display this help and exit > @item -V, --version > output version information and exit > + > + Note: When qemu-nbd was used to export a disk that would be used by QEMU > +block device, -t or --persistent must be set for that QEMU nbd client would try > +connect more than one time. For eg: > + qemu-nbd ./simple.img -p 10809 -t > + qemu -hdb nbd:127.0.0.1:10809 It is not accurate. qemu connect to nbd server not "several" but exactly two times by default. The first connection it does (it need not be a separate connection actually, and this, I'd say, a bug in qemu) in order to guess the format of the internal structure inside - be it raw, or qcow, or anything else. So, if you specify the format of the device explicitly, by using format=raw, only single connection will be made. /mjt
> On 03.07.2012 15:05, xiawenc@linux.vnet.ibm.com wrote: >> From: Wenchao Xia<xiawenc@linux.vnet.ibm.com> >> >> Qemu system emulator reports only fails that make people confused >> about why, when it is invoked with nbd block device tring to connect >> qemu-nbd server. In fact qemu will try connect server for several >> times but server only accept one connect by default. >> I paid some times to find out why it fails. This patch add special >> text to explain how to use it in such case. >> >> Signed-off-by: Wenchao Xia<xiawenc@linux.vnet.ibm.com> >> --- >> qemu-nbd.texi | 6 ++++++ >> 1 files changed, 6 insertions(+), 0 deletions(-) >> >> diff --git a/qemu-nbd.texi b/qemu-nbd.texi >> index 6955d90..014040a 100644 >> --- a/qemu-nbd.texi >> +++ b/qemu-nbd.texi >> @@ -44,6 +44,12 @@ Export QEMU disk image using NBD protocol. >> display this help and exit >> @item -V, --version >> output version information and exit >> + >> + Note: When qemu-nbd was used to export a disk that would be used by QEMU >> +block device, -t or --persistent must be set for that QEMU nbd client would try >> +connect more than one time. For eg: >> + qemu-nbd ./simple.img -p 10809 -t >> + qemu -hdb nbd:127.0.0.1:10809 > > It is not accurate. > > qemu connect to nbd server not "several" but exactly two times by default. > The first connection it does (it need not be a separate connection > actually, and this, I'd say, a bug in qemu) in order to guess the format I think so, actually I planned to patch qemu client side to make it connect only once, but the disconnect logical lies in general block layer and changing of that may break other block device logical I guess, so I gave up of that approach. > of the internal structure inside - be it raw, or qcow, or anything else. > So, if you specify the format of the device explicitly, by using > format=raw, only single connection will be made. thanks, that helped me. A bit more question: is there a way to let nbd client know the image format used by server? qemu-nbd exports simple_qcow2.img, and qemu saw it as raw block device, is it possible to get the information in qemu that server is using qcow2 image? > > /mjt >
于 2012-7-3 19:55, Paolo Bonzini 写道: > Il 03/07/2012 13:05, xiawenc@linux.vnet.ibm.com ha scritto: >> + >> + Note: When qemu-nbd was used to export a disk that would be used by QEMU >> +block device, -t or --persistent must be set for that QEMU nbd client would try >> +connect more than one time. For eg: >> + qemu-nbd ./simple.img -p 10809 -t >> + qemu -hdb nbd:127.0.0.1:10809 > > We could actually make persistent the default unless we're using > qemu-nbd in client mode (i.e. exporting to /dev/nbd*), and drop the > option. What do you think? > I think there will be no harm to make persistent default, but mark this change in document in case of breaking potential user case.(maybe someone have used qemu and expect qemu-nbd exit in script). > Paolo >
于 2012-7-4 0:18, 陳韋任 (Wei-Ren Chen) 写道: >> + >> + Note: When qemu-nbd was used to export a disk that would be used by QEMU >> +block device, -t or --persistent must be set for that QEMU nbd client would try >> +connect more than one time. For eg: > ^^^^^^ > Not a native english speaker, but I never see such usage before. > Should be "For example"? > Sorry it should be "i.e." or "for example", my bad spell custom. > Regards, > chenwj >
Il 04/07/2012 04:14, Wayne Xia ha scritto: > >> of the internal structure inside - be it raw, or qcow, or anything else. >> So, if you specify the format of the device explicitly, by using >> format=raw, only single connection will be made. > thanks, that helped me. A bit more question: is there a way to let > nbd client know the image format used by server? qemu-nbd exports > simple_qcow2.img, and qemu saw it as raw block device, is it possible to > get the information in qemu that server is using qcow2 image? qemu-nbd takes care of the format translation itself, and always exposes the image as raw. Paolo
Am 03.07.2012 21:45, schrieb Michael Tokarev: > On 03.07.2012 15:05, xiawenc@linux.vnet.ibm.com wrote: >> From: Wenchao Xia <xiawenc@linux.vnet.ibm.com> >> >> Qemu system emulator reports only fails that make people confused >> about why, when it is invoked with nbd block device tring to connect >> qemu-nbd server. In fact qemu will try connect server for several >> times but server only accept one connect by default. >> I paid some times to find out why it fails. This patch add special >> text to explain how to use it in such case. >> >> Signed-off-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com> >> --- >> qemu-nbd.texi | 6 ++++++ >> 1 files changed, 6 insertions(+), 0 deletions(-) >> >> diff --git a/qemu-nbd.texi b/qemu-nbd.texi >> index 6955d90..014040a 100644 >> --- a/qemu-nbd.texi >> +++ b/qemu-nbd.texi >> @@ -44,6 +44,12 @@ Export QEMU disk image using NBD protocol. >> display this help and exit >> @item -V, --version >> output version information and exit >> + >> + Note: When qemu-nbd was used to export a disk that would be used by QEMU >> +block device, -t or --persistent must be set for that QEMU nbd client would try >> +connect more than one time. For eg: >> + qemu-nbd ./simple.img -p 10809 -t >> + qemu -hdb nbd:127.0.0.1:10809 > > It is not accurate. > > qemu connect to nbd server not "several" but exactly two times by default. > The first connection it does (it need not be a separate connection > actually, and this, I'd say, a bug in qemu) in order to guess the format > of the internal structure inside - be it raw, or qcow, or anything else. I think I agree that we should get rid of this behaviour. It's going to bite us with fd passing as well. It should be possible to open the protocol first and the use that open BlockDriverState both for probing and for the real open. Kevin
于 2012-7-3 19:55, Paolo Bonzini 写道: > Il 03/07/2012 13:05, xiawenc@linux.vnet.ibm.com ha scritto: >> + >> + Note: When qemu-nbd was used to export a disk that would be used by QEMU >> +block device, -t or --persistent must be set for that QEMU nbd client would try >> +connect more than one time. For eg: >> + qemu-nbd ./simple.img -p 10809 -t >> + qemu -hdb nbd:127.0.0.1:10809 > > We could actually make persistent the default unless we're using > qemu-nbd in client mode (i.e. exporting to /dev/nbd*), and drop the > option. What do you think? > > Paolo > Hi Paolo, should I make a patch to make persistent the default for qemu-nbd?
Il 05/07/2012 05:29, Wayne Xia ha scritto: >> >>> + >>> + Note: When qemu-nbd was used to export a disk that would be used >>> by QEMU >>> +block device, -t or --persistent must be set for that QEMU nbd >>> client would try >>> +connect more than one time. For eg: >>> + qemu-nbd ./simple.img -p 10809 -t >>> + qemu -hdb nbd:127.0.0.1:10809 >> >> We could actually make persistent the default unless we're using >> qemu-nbd in client mode (i.e. exporting to /dev/nbd*), and drop the >> option. What do you think? >> >> Paolo >> > Hi Paolo, should I make a patch to make persistent the default for > qemu-nbd? Yes, why not. However, as mentioned above client mode should still be non-persistent. Paolo
On 05.07.2012 10:42, Paolo Bonzini wrote: > Il 05/07/2012 05:29, Wayne Xia ha scritto: [] >> Hi Paolo, should I make a patch to make persistent the default for >> qemu-nbd? > > Yes, why not. However, as mentioned above client mode should still be > non-persistent. I don't think this makes sense or is good: now we'll need to have an option to enable non-persistent mode, and have to fix scripts which expects non-persistent mode by default (does autotest uses it?). Instead, it is more productive and rigth (IMHO anyway) to fix the qemu side to stop connecting two times for one device. thanks, /mjt
Il 05/07/2012 10:13, Michael Tokarev ha scritto: >>> >> Hi Paolo, should I make a patch to make persistent the default for >>> >> qemu-nbd? >> > >> > Yes, why not. However, as mentioned above client mode should still be >> > non-persistent. > I don't think this makes sense or is good: now we'll need > to have an option to enable non-persistent mode, and have > to fix scripts which expects non-persistent mode by default > (does autotest uses it?). Hmm, yeah, with daemon mode non-persistent is still better. I guess it is just a bogus thing we have to live with, just like daemon mode itself. > Instead, it is more productive and rigth (IMHO anyway) to > fix the qemu side to stop connecting two times for one > device. That too. Paolo
于 2012-7-5 16:34, Paolo Bonzini 写道: > Il 05/07/2012 10:13, Michael Tokarev ha scritto: >>>>>> Hi Paolo, should I make a patch to make persistent the default for >>>>>> qemu-nbd? >>>> >>>> Yes, why not. However, as mentioned above client mode should still be >>>> non-persistent. >> I don't think this makes sense or is good: now we'll need >> to have an option to enable non-persistent mode, and have >> to fix scripts which expects non-persistent mode by default >> (does autotest uses it?). > > Hmm, yeah, with daemon mode non-persistent is still better. I guess it > is just a bogus thing we have to live with, just like daemon mode itself. > From the product perspective, keeping qemu-nbd option unchanged seems better. I think changing the qemu block behavior needs extra efforts and not so worthy. Actually I don't think this is a bug, the nbd-block still works but just need some document to avoid making user debug it. Maybe a document is the easiest way. >> Instead, it is more productive and rigth (IMHO anyway) to >> fix the qemu side to stop connecting two times for one >> device. > > That too. > > Paolo >
Paolo, what do you think write a short section in document for it, but make no change to code? > 于 2012-7-5 16:34, Paolo Bonzini 写道: >> Il 05/07/2012 10:13, Michael Tokarev ha scritto: >>>>>>> Hi Paolo, should I make a patch to make persistent the default for >>>>>>> qemu-nbd? >>>>> >>>>> Yes, why not. However, as mentioned above client mode should still be >>>>> non-persistent. >>> I don't think this makes sense or is good: now we'll need >>> to have an option to enable non-persistent mode, and have >>> to fix scripts which expects non-persistent mode by default >>> (does autotest uses it?). >> >> Hmm, yeah, with daemon mode non-persistent is still better. I guess it >> is just a bogus thing we have to live with, just like daemon mode itself. >> > From the product perspective, keeping qemu-nbd option unchanged seems > better. I think changing the qemu block behavior needs extra efforts > and not so worthy. Actually I don't think this is a bug, the nbd-block > still works but just need some document to avoid making user debug it. > Maybe a document is the easiest way. > >>> Instead, it is more productive and rigth (IMHO anyway) to >>> fix the qemu side to stop connecting two times for one >>> device. >> >> That too. >> >> Paolo >> > >
Il 09/07/2012 09:11, Wayne Xia ha scritto: > Paolo, what do you think write a short section in document for it, but > make no change to code? That's okay, but perhaps for 1.2 we can fix the probing. I'll apply the patch to nbd-next and not submit it until it's clear that 1.2 will still have the bug. Paolo
diff --git a/qemu-nbd.texi b/qemu-nbd.texi index 6955d90..014040a 100644 --- a/qemu-nbd.texi +++ b/qemu-nbd.texi @@ -44,6 +44,12 @@ Export QEMU disk image using NBD protocol. display this help and exit @item -V, --version output version information and exit + + Note: When qemu-nbd was used to export a disk that would be used by QEMU +block device, -t or --persistent must be set for that QEMU nbd client would try +connect more than one time. For eg: + qemu-nbd ./simple.img -p 10809 -t + qemu -hdb nbd:127.0.0.1:10809 @end table @c man end