On 03/09/2016 03:32 PM, Huttunen, Janne (Nokia - FI/Espoo) wrote: >> I just pushed some changes in the master branch that should >> provide this capability. Can you try them out? > First of all, I do appreciate your effort (without > ipmi_sim I couldn't do what I'm currently doing at > all), so don't take anything below too seriously :-) > > > I haven't had the opportunity to try this out yet > (I have been running with the extra socat in the > middle as a workaround), but just after a quick > glance at the new code: > > Isn't the connection the wrong way round?
I considered this, and I decided that it's more general to have ipmi_sim do the connection. That way it will work with things besides qemu (terminal servers, etc.) Also, if you are a telnet server, there is no way to send a serial break to the other end. That's a pretty significant use case. > Obviously it's good to have more flexibility and > the abstractions you implemented seem good to have, > but I thought the connection would be so that > ipmi_sim would act as the server. The way I see it, > there are basically two ways to use ipmi_sim with > QEMU: > > 1. QEMU is started outside of ipmi_sim and never > exits. > 2. QEMU is started and killed by ipmi_sim. > > Of these two, I think the the first one is already > pretty neatly covered by configuring QEMU to create > a pty and configuring ipmi_sim to attach into that > (ok, it seems to be missing some nice way to figure > out the correct pty, like e.g. QEMU creating symlink > into it, but still), so while it now can use TCP for > it, which is nice, it doesn't feel all that necessary. > > In the second use case, the ipmi_sim exists before > the QEMU is started. In this case it would be hard > to use a pty created by QEMU for the SoL since there > is no nice way to pass the pty to ipmi_sim. IMHO this > is the use case that would benefit most from some > alternative means to form the connection (and is the > one that I'm currently using), but since it's ipmi_sim > that exists first, it would feel natural to me that it > would be the server and QEMU would connect to it while > it is running. If I did read the code right, ipmi_sim > currently only supports client mode, which feels to > be the wrong way for my use case. The whole problem with using ptys revolves around identifying the pty name to ipmi_sim. There is no easy way to do this. Modifying qemu to create a symlink would be the best I can think of. If that is done, then the patches I added also added a retry mechanism so that if the other end goes away, it will attempt to retry the connection every 10 seconds. So then it would work for the above cases. Plus you can't send a break over a pty. Poking around through the qemu code (I know this particular piece of code pretty well as I did some extensions to it recently) you could write a daemon that connects to a monitor port for qemu, figures out the pty name, and creates a symlink. The pty slave name is given in the device listing for the pty. It would also be very easy to add creating a symlink into qemu. But the telnet socket option works just as well, I think. As long as you assign the socket address to local-only, I don't think there are any more security implications. I can't see any disadvantages to the serial port, am I missing something? -corey > > > Anyways, I hope to have the time to check out the > implementation more thoroughly in the future. In the > mean time, feel free to let me know if I have missed > something obvious. > ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
