Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Jorge Lucángeli Obes schrieb: qemu: could not open hard disk image '@config' I think this was a suggestion for implementation, not a working feature. I did not know about '@config', and if I can get it to work, I like it better than a shell script. However, I think it does not completely solve the problem. It still means two files per VM. As long as it is not possible to store more than one image in one file, this problem won't be solved completely anyway. Kevin
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Thiemo Seufer wrote: Jorge Lucángeli Obes wrote: [snip] When I read Avi's TODO, I basically thought about getting rid of the long command lines I had to store in scripts. I wanted to write that command line once, and then forgetting about it, until I needed to change it. Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg where qemu.cfg is a file which contains the command line arguments. (This is also low-maintenance, as it allows to re-use the existing IMHO, it should be implemented at the shell level, not qemu level, like * is. Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature
[Qemu-devel] adding support for above 2giga for qemu. ( include patchs )
hey, i have wrote a patch to qemu to allow it to run with above the 2giga limitations we have now. i tested it on qemu that used kvm with 14giga of ram, and it was tested at other place with 32giga of ram to the guest ( 32bits, and 64bits). the patch that i send here, is patch to qemu without kvm, it include patch to the bochs bios, and patch to the qemu. part of the patch to qemu fix the typedefs varibles to unsigned long, and it is based on patch i saw at this list that target sparc. for some reason the mapping that i do inside qemu with cpu_register_physical_memory dont work, and with this patchs qemu could not work with more than 3.75giga of ram. ( with kvm it does working... ) this is request for comment, i probbley doing something wrong inside qemu, so anyone have idea how to solve it please comment :) anyway for to make it easy to run i put here compiled patched bios. have fun! :-) bochs_bios_ram_patch Description: bochs_bios_ram_patch qemu_ram_patch Description: qemu_ram_patch
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 14 Aug 2007, at 00:31, Thiemo Seufer wrote: Philip Boulain wrote: On 13 Aug 2007, at 20:39, Thiemo Seufer wrote: ...implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg I'm not familiar with that. Is it just GNU bash shorthand for qemu `cat qemu.cfg` ? I don't think it has anything to do with bash. Apparently Windows(NT) cmd.exe introduced this as a way to avoid unwieldy command lines. Cygwin (or MingGW?) added the same to their tools in order to avoid command line length problems. Not so long ago it was implemented for gcc and binutils... Ugh. This is in-application magic that does a pre-parsing step on argv []? I'm suddenly being flooded with horrible memories of how Win-DOS requires each individual application to implement its own wildcards in arguments, and how these implementations were inevitably inconsistent in ways that stabbed you in the face. Maybe QEMU /should/ have a ...and read this file as arguments... argument, but this really doesn't seem a good way to do it. -c qemu.cfg is a lot less ambiguous, as you don't have to worry about whether an '@' in an argument is an include command, or a literal, e.g. part of a filename (it could be either, and escaping it at the shell level won't help). LionsPhil
Re: [Qemu-devel] PATCH 0/8: Authentication support for the VNC server
These all look good to me! Regards, Anthony Liguori On Mon, 2007-08-13 at 20:25 +0100, Daniel P. Berrange wrote: The current VNC server implementation does not have support for the authentication of incoming client connections. The following series of patches provide support for a number of alternatives, all compliant with the VNC protocol spec. The simplest mechanism (and the weakest) is the traditional VNC password scheme based on weak d3des hashing of an 8 byte key. The more serious mechanism uses TLS for data encryption of the entire session, and x509 certificates for both client and server authentication. The patches are an iteration on the previous work I posted a couple of weeks ago[1]. This addresses all the issues raised in the previous review along with a couple of edge cases I discovered. Since TLS can be quite perplexing, I also included some documentation on how to setup a CA, and issue client server certs in a manner suitable for use with the VNC server. For the basic VNC password auth, this patch should be compatible with any standard VNC client such as RealVNC. The TLS based auth schemes require a client that implements the VeNCrypt extension[2]. The client from the VeNCrypt[3] project of course is one example. The GTK-VNC[4] widget which is used by Virt Manager[5] and Vinagre [6] also support it, and are my primary testing platform. The 8 individual patches will follow shortly in replies to this mail. Regards, Dan. [1] http://www.mail-archive.com/qemu-devel@nongnu.org/msg11554.html [2] http://www.mail-archive.com/qemu-devel@nongnu.org/msg08681.html [3] http://sourceforge.net/projects/vencrypt/ [4] http://gtk-vnc.sourceforge.net/ [5] http://virt-manager.org/ [6] http://www.gnome.org/~jwendell/vinagre/
