[Qemu-devel] What can qemu do that vmware/virtual pc can't...article idea
Hi List. I'm in contact with one of the writers for the german (large) computer magazine c't (computer and technology) defending qemu (he neglected some features qemu has in one of his articles). Now he asks me for an article about what the "average user" would benefit from when he would use qemu instead of virtual pc/vmware (their "free" products, like player, ESX ...). The examples I named up to now where qemu -nographic -hda linux.img -kernel linux-2.6.17.6/arch/i386/boot/bzImage -append "console=ttyS0 root=/dev/hda ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe" -hdb fat:/mnt/data/Projekte/qemu/linux-test/bla doing a little linux kernel driver development learning this way. (Good free pdf over at oreilly) Also, when testing OCFS2 (Oracle cluster fs 2) and not having a SAN/iSCSI system at hand I tried this: qemu -hda breezy.img -hdb ocsf2.img mounting that image once qemu -hda breezy.img -hdb ocsf2.img and now mounting it again in a second instance of qemu with slightly different network setup. That works with qemu, vmware desktop wouldn't take the image a second time. Also, a demonstration LiveCD could be made to boot on a system but also to be played with qemu/qvm86 under win and linux (kqemu can't be re-distributed). There would be statically built qemu's on the CD with bat/bash skripts to start them (automatically). Also, qemu can run happily on the server awaiting connects via vnc. But some of the free products can do that too. Soo, do you have any more ideas what qemu can what the (free) alternatives from M$/VMWare can't? Virtual PC can't handle USB _at_all_, what's the status of USB2.0 with qemu ( I think VMWare is still stuck on USB 1.1 )? VMWare Desktop (not free) has "unlimited" snapshots IIRC, ESX just recently got one snapshot functionality. I can't say if I would do the article or the writer for the magazine but at least it would make qemu more visible to (more technical inclined) people -> good in my eyes. Thanks for your suggestions Cheers Udo -- Robos - gpg --recv-keys --keyserver blackhole.pca.dfn.de 6EEADA09 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] What can qemu do that vmware/virtual pc can't...article idea
Udo 'Robos' Puetz wrote: Hi List. I'm in contact with one of the writers for the german (large) computer magazine c't (computer and technology) defending qemu (he neglected some features qemu has in one of his articles). Now he asks me for an article about what the "average user" would benefit from when he would use qemu instead of virtual pc/vmware (their "free" products, like player, ESX ...). The examples I named up to now where qemu -nographic -hda linux.img -kernel linux-2.6.17.6/arch/i386/boot/bzImage -append "console=ttyS0 root=/dev/hda ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe" -hdb fat:/mnt/data/Projekte/qemu/linux-test/bla doing a little linux kernel driver development learning this way. (Good free pdf over at oreilly) Also, when testing OCFS2 (Oracle cluster fs 2) and not having a SAN/iSCSI system at hand I tried this: qemu -hda breezy.img -hdb ocsf2.img mounting that image once qemu -hda breezy.img -hdb ocsf2.img and now mounting it again in a second instance of qemu with slightly different network setup. That works with qemu, vmware desktop wouldn't take the image a second time. Also, a demonstration LiveCD could be made to boot on a system but also to be played with qemu/qvm86 under win and linux (kqemu can't be re-distributed). There would be statically built qemu's on the CD with bat/bash skripts to start them (automatically). Also, qemu can run happily on the server awaiting connects via vnc. But some of the free products can do that too. Soo, do you have any more ideas what qemu can what the (free) alternatives from M$/VMWare can't? Virtual PC can't handle USB _at_all_, what's the status of USB2.0 with qemu ( I think VMWare is still stuck on USB 1.1 )? VMWare Desktop (not free) has "unlimited" snapshots IIRC, ESX just recently got one snapshot functionality. I can't say if I would do the article or the writer for the magazine but at least it would make qemu more visible to (more technical inclined) people -> good in my eyes. Thanks for your suggestions Cheers Udo Maybe qemu is not of so much use for the desktop user, but has its strength more in the direction of a generic "computer emulator" platform where other projects can build upon (see Argos or Free Live OS Zoo). I'm not sure if Qemu really can compete with VMWare for a desktop virtualization software. In my opinion the big advantage of Qemu is that it's open source. That makes it possible to use it as a basis for other projects; that also makes it possible to build the Live CD you mentioned. Another point is that an open source software is more likely to be shipped with Linux distros (OTOH VMPlayer is already available in some Ubuntu package repository, so this depends more on the distro maintainers). And if one wants to have a reliable platform to run legacy applications, an open source software has the advantage that you're not dependent on some company that might not exist in twenty years. Another point is the support of many host and guest platforms. But I think all this doesn't really help the desktop user. What I think is quite nice is the USB tablet emulation. At least VMware requires that the VMWare tools are installed for mouse switching between host and guest. It's quite astounding that in Qemu this works (at least with Windows guest) without installing additional software. So, IMHO you shouldn't try to praise Qemu as an end-user desktop virtualization software; presenting it to more technical users seems like a better idea. Regards, Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] What can qemu do that vmware/virtual pc can't...article idea
Udo 'Robos' Puetz wrote: > Soo, do you have any more ideas what qemu can what the (free) alternatives > from M$/VMWare can't? > Qemu can be used without the need to install anything, which is especially useful if you put a preconfigured OS image plus qemu binaries (for different host OS') and startup scripts on a dvd. Additionally it's very nice in this context, that qemu does not need admin/root priviledges. hth, Jan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] What can qemu do that vmware/virtual pc can't...article idea
Oliver Gerlich wrote: > So, IMHO you shouldn't try to praise Qemu as an end-user desktop > virtualization software; presenting it to more technical users seems > like a better idea. Not necessarily. It is true that QEMU offers a load of features that technical users will enjoy, but also various desktop user-oriented projects use it as an engine for their products. These include GUI front-ends, various extensions for popular desktop environments, etc. This effectively makes QEMU *the* emulator for the Free software community. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] /dev/rtc
G'day all,
Been playing with multiple vm's on linux and hacking around my suspend/resume
dropped interrupt issues.
I just noticed the /dev/rtc interface appears to be very single use oriented.
If I run multiple vm's
simultaneously on the same machine, the 1st one picks up the interrupt driven timer and the rest
must revert to userspace based timers.
open("/dev/rtc", O_RDONLY|O_LARGEFILE) = -1 EBUSY (Device or resource busy)
Not having investigated this much further as I'm testing on a fairly low powered device, but I
wonder how this impacts server applications where we desire to run several qemu instances concurrently.
(I have already played with dropping the timer interrupt rate back from 1024 to 256 and it really
does not appear to impact my linux guests, but it makes my windows guests audio unusable. Still
experimenting with that)
Just fishing for comments really.. wondering about some form of shared interrupt timing device to
allow multiple instances to run with full timer resolution or if it really even matters.
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] What can qemu do that vmware/virtual pc can't...article idea
Soo, do you have any more ideas what qemu can what the (free) alternatives from M$/VMWare can't? I must admit I haven't used Virtual PC and have no idea about what it can do, but I tried VMWare. In terms of using, apart from the source code, I think the biggest advantage of QEMU is the amount of hardware it can emulate. There's a number of input devices, graphics cards, NICs, storage devices and above all CPUs. VMWare can do only a very little part of this, and it doesn't emulate the CPU at all, it only virtualises it. It won't run on a platform different than i386 or with a guest different than i386. So, QEMU is a quite generic computer emulator and I don't know if the word "alternatives" can be used because they don't have the functionality that I personally exploit in QEMU. Also, if I was forced to use VMWare for some reason, I would miss the flexibility of -monitor, -serial, and the options related to the graphics display, as well as the debug info I can get from QEMU. Regards, -- balrog 2oo6 Dear Outlook users: Please remove me from your address books http://www.newsforge.com/article.pl?sid=03/08/21/143258 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] What can qemu do that vmware/virtual pc can't...article idea
On Fri, 28 Jul 2006 15:58:06 +0200 Udo 'Robos' Puetz <[EMAIL PROTECTED]> wrote: > Soo, do you have any more ideas what qemu can what the (free) > alternatives from M$/VMWare can't? Well, in addition to system emulation qemu that I'd guess most users want qemu for, it has "user" emulation where you can run for xample an ARM binary on an x86 host. It also emulates many targets, not just the x86/x86_64 that VMware or VirtualPC support - bear in mind these are virtualisation tools, not emulators, where as qemu is primarily an emulator with virtualisation acceleration for native x86/x86_64 targets. This makes qemu great for cross-target development. See www.scratchbox.org for example. Obviously qemu also has the advantage that (apart from the virualisation module kqemu) it's open source, which means a lot to many people, at least for me! -- Kevin F. Quinn signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] How to Simulate hardware that counts scanlines?
On 7/27/06, Steve Ellenoff <[EMAIL PROTECTED]> wrote: The guest os code is polling this register on a very fast interval, and when it detects a certain # of scanlines have been counted, it will swap it's display buffers, ie, it's waiting for the vblank, so it can have nice smooth animations. Since this is all custom, I'd rather raise an interrupt when the DAC reaches the final portion of the frame buffer... This has to be better than polling. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: FreeBSD qemu 0.8.2 update - please test! (and usb cardreader SET_ADDR_FAILED)
On Tue, Jul 25, 2006 at 07:06:02PM -0400, Jung-uk Kim wrote:
> On Tuesday 25 July 2006 01:47 pm, Juergen Lock wrote:
> > @@ -47,21 +43,20 @@
> > void set_float_rounding_mode(int val STATUS_PARAM)
> > {
> > STATUS(float_rounding_mode) = val;
> > --#if defined(_BSD) && !defined(__APPLE__)
> > -+#if defined(_BSD) && !defined(__APPLE__) && \
> > -+(defined(__FreeBSD__) && __FreeBSD_version < 50)
> > +-#if defined(_BSD) && !defined(__APPLE__) || (defined(HOST_SOLARIS) &&
> > HOST_SOLARIS < 10)
> > ++#if (defined(_BSD) && (defined(__FreeBSD__) && __FreeBSD_version <
> > 50)) && !defined(__APPLE__) || (defined(HOST_SOLARIS) && HOST_SOLARIS <
> > 10)
> > fpsetround(val);
> > #elif defined(__arm__)
> > /* nothing to do */
>
> FYI, a parenthesis is misplaced (Note: I just rearranged
> the order to be more clearer):
>
> +-#if defined(_BSD) && !defined(__APPLE__) || (defined(HOST_SOLARIS) &&
> HOST_SOLARIS < 10)
> ++#if (defined(_BSD) && !defined(__APPLE__) && (defined(__FreeBSD__) &&
> __FreeBSD_version < 50)) || \
> ++(defined(HOST_SOLARIS) && HOST_SOLARIS < 10)
Well this should actually be:
#if defined(_BSD) && !defined(__APPLE__) && !defined(__FreeBSD__) || \
(defined(__FreeBSD__) && __FreeBSD_version < 50) || \
(defined(HOST_SOLARIS) && HOST_SOLARIS < 10)
if it ever was going to be merged back. (wrongly excluded non-FreeBSD BSDs)
>
> Actually it is an upstream bug, though.
Nah, the parens there are okay... (|| binds less than &&, i.e.
1 || 0 && 0 evaluates to 1.)
On another note, am i the only one seeing those -kernel-kqemu problems?
thanx,
Juergen
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [RFC][PATCH] make sure disk writes actually hit disk
This is the simple approach to making sure that disk writes actually
hit disk before we tell the guest OS that IO has completed. Thanks
to DMA_MULTI_THREAD the performance still seems to be adequate.
A fancier solution would be to make the sync/non-sync behaviour of
the qemu disk backing store tunable from the guest OS, by tuning
the IDE disk write cache on/off with hdparm, and having hw/ide.c
call ->fsync functions in the block backends.
I'm willing to code up the fancy solution if people prefer that.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Make sure disk writes really made it to disk before we report I/O
completion to the guest domain. The DMA_MULTI_THREAD functionality
from the qemu-dm IDE emulation should make the performance overhead
of synchronous writes bearable, or at least comparable to native
hardware.
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
--- xen-unstable-10712/tools/ioemu/block-bochs.c.osync 2006-07-28 02:15:56.0 -0400
+++ xen-unstable-10712/tools/ioemu/block-bochs.c 2006-07-28 02:21:08.0 -0400
@@ -91,7 +91,7 @@
int fd, i;
struct bochs_header bochs;
-fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE);
+fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE | O_SYNC);
if (fd < 0) {
fd = open(filename, O_RDONLY | O_BINARY | O_LARGEFILE);
if (fd < 0)
--- xen-unstable-10712/tools/ioemu/block.c.osync 2006-07-28 02:15:56.0 -0400
+++ xen-unstable-10712/tools/ioemu/block.c 2006-07-28 02:19:27.0 -0400
@@ -677,7 +677,7 @@
int rv;
#endif
-fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE);
+fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE | O_SYNC);
if (fd < 0) {
fd = open(filename, O_RDONLY | O_BINARY | O_LARGEFILE);
if (fd < 0)
--- xen-unstable-10712/tools/ioemu/block-cloop.c.osync 2006-07-28 02:15:56.0 -0400
+++ xen-unstable-10712/tools/ioemu/block-cloop.c 2006-07-28 02:17:13.0 -0400
@@ -55,7 +55,7 @@
BDRVCloopState *s = bs->opaque;
uint32_t offsets_size,max_compressed_block_size=1,i;
-s->fd = open(filename, O_RDONLY | O_BINARY | O_LARGEFILE);
+s->fd = open(filename, O_RDONLY | O_BINARY | O_LARGEFILE | O_SYNC);
if (s->fd < 0)
return -1;
bs->read_only = 1;
--- xen-unstable-10712/tools/ioemu/block-cow.c.osync 2006-07-28 02:15:56.0 -0400
+++ xen-unstable-10712/tools/ioemu/block-cow.c 2006-07-28 02:21:34.0 -0400
@@ -69,7 +69,7 @@
struct cow_header_v2 cow_header;
int64_t size;
-fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE);
+fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE | O_SYNC);
if (fd < 0) {
fd = open(filename, O_RDONLY | O_BINARY | O_LARGEFILE);
if (fd < 0)
--- xen-unstable-10712/tools/ioemu/block-qcow.c.osync 2006-07-28 02:15:56.0 -0400
+++ xen-unstable-10712/tools/ioemu/block-qcow.c 2006-07-28 02:20:05.0 -0400
@@ -95,7 +95,7 @@
int fd, len, i, shift;
QCowHeader header;
-fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE);
+fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE | O_SYNC);
if (fd < 0) {
fd = open(filename, O_RDONLY | O_BINARY | O_LARGEFILE);
if (fd < 0)
--- xen-unstable-10712/tools/ioemu/block-vmdk.c.osync 2006-07-28 02:15:56.0 -0400
+++ xen-unstable-10712/tools/ioemu/block-vmdk.c 2006-07-28 02:20:20.0 -0400
@@ -96,7 +96,7 @@
uint32_t magic;
int l1_size;
-fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE);
+fd = open(filename, O_RDWR | O_BINARY | O_LARGEFILE | O_SYNC);
if (fd < 0) {
fd = open(filename, O_RDONLY | O_BINARY | O_LARGEFILE);
if (fd < 0)
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: [RFC][PATCH] make sure disk writes actually hit disk
Rik van Riel wrote: This is the simple approach to making sure that disk writes actually hit disk before we tell the guest OS that IO has completed. Thanks to DMA_MULTI_THREAD the performance still seems to be adequate. Hah, and of course that bit is only found in Xen's qemu-dm. Doh! I knew I should have also checked some of the files my patch didn't touch :) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: [RFC][PATCH] make sure disk writes actually hit disk
On Fri, 28 Jul 2006 15:54:30 -0400, Rik van Riel wrote: > This is the simple approach to making sure that disk writes actually hit > disk before we tell the guest OS that IO has completed. Thanks to > DMA_MULTI_THREAD the performance still seems to be adequate. Hi Rik, Right now Fabrice is working on rewriting the block API to be asynchronous. There's been quite a lot of discussion about why using threads isn't a good idea for this (I wish Xen wouldn't use this patch but that's another conversation :-)). The async block API will allow the use of different kinds of async "backends". The default (on Linux) will be posix-aio. I'm currently working on an HTTP backend and will also write a linux-aio (which, of course, will be using O_DIRECT). > A fancier solution would be to make the sync/non-sync behaviour of the > qemu disk backing store tunable from the guest OS, by tuning the IDE disk > write cache on/off with hdparm, and having hw/ide.c call ->fsync functions > in the block backends. With a proper async API, is there any reason why we would want this to be tunable? I don't think there's much of a benefit of prematurely claiming a write is complete especially once the SCSI emulation can support multiple simultaneous requests. I was hoping to just make linux-aio the default if it was available... Regards, Anthony Liguori > I'm willing to code up the fancy solution if people prefer that. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: [RFC][PATCH] make sure disk writes actually hit disk
Anthony Liguori wrote: Right now Fabrice is working on rewriting the block API to be asynchronous. There's been quite a lot of discussion about why using threads isn't a good idea for this Agreed, AIO is the way to go in the long run. With a proper async API, is there any reason why we would want this to be tunable? I don't think there's much of a benefit of prematurely claiming a write is complete especially once the SCSI emulation can support multiple simultaneous requests. You're right. This O_SYNC bandaid should probably stay in place to prevent data corruption, until the AIO framework is ready to be used. No sense investing too much time in a fancier band-aid. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: [RFC][PATCH] make sure disk writes actually hit disk
> > With a proper async API, is there any reason why we would want this to be > > tunable? I don't think there's much of a benefit of prematurely claiming > > a write is complete especially once the SCSI emulation can support > > multiple simultaneous requests. > > You're right. This O_SYNC bandaid should probably stay in place > to prevent data corruption, until the AIO framework is ready to > be used. It's arguable whether O_SYNC is needed at all. Qemu doesn't claim data is written to disk, and provides facilities for the guest OS to flush the cache, just like real hardware does. Have you measured the impact of O_SYNC? I wouldn't be surprised if it was significant. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: [RFC][PATCH] make sure disk writes actually hit disk
Paul Brook wrote: With a proper async API, is there any reason why we would want this to be tunable? I don't think there's much of a benefit of prematurely claiming a write is complete especially once the SCSI emulation can support multiple simultaneous requests. You're right. This O_SYNC bandaid should probably stay in place to prevent data corruption, until the AIO framework is ready to be used. It's arguable whether O_SYNC is needed at all. Qemu doesn't claim data is written to disk, and provides facilities for the guest OS to flush the cache, just like real hardware does. Nice. Another difference between the qemu codebase and the qemu-dm codebase used by Xen. With the bdrv_flush stuff in place, it should even be easy for qemu to actually do something when the guest OS switches disk write caching off (currently that is a noop in the qemu code base). Have you measured the impact of O_SYNC? I wouldn't be surprised if it was significant. I suspect it'll be horrific in the qemu codebase (blocking execution of the guest OS until disk IO is complete), but it's fine in the Xen qemu-dm situation, where IO completion happens asynchronously. The recent commit message on the Xen side did not suggest there was that much of a difference between both qemu code bases. Obviously I was wrong, and the O_SYNC bandaid should probably be kept out for now. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: [RFC][PATCH] make sure disk writes actually hit disk
> > Have you measured the impact of O_SYNC? I wouldn't be surprised if it was > > significant. > > I suspect it'll be horrific in the qemu codebase (blocking execution > of the guest OS until disk IO is complete), but it's fine in the Xen > qemu-dm situation, where IO completion happens asynchronously. > > The recent commit message on the Xen side did not suggest there was > that much of a difference between both qemu code bases. Obviously > I was wrong, and the O_SYNC bandaid should probably be kept out for > now. Ah, ok. I didn't realise they'd diverged that much either. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] specify device_name for commit
Hello all!
With this patch only the specified device gets commited.
Since this is my first attempt to send a patch to the list, please let
me know what you think of it.
cheers
m.
Index: monitor.c
===
RCS file: /sources/qemu/qemu/monitor.c,v
retrieving revision 1.54
diff -u -r1.54 monitor.c
--- monitor.c 16 Jul 2006 18:57:03 - 1.54
+++ monitor.c 28 Jul 2006 21:32:45 -
@@ -24,6 +24,7 @@
#include "vl.h"
#include "disas.h"
#include
+#include "block_int.h"
//#define DEBUG
//#define DEBUG_COMPLETION
@@ -167,13 +168,15 @@
help_cmd(name);
}
-static void do_commit(void)
+static void do_commit(const char *device)
{
-int i;
-
+int i, all_devices;
+
+all_devices = !strcmp(device, "all");
for (i = 0; i < MAX_DISKS; i++) {
if (bs_table[i]) {
-bdrv_commit(bs_table[i]);
+ if (all_devices || !strcmp(bs_table[i]->device_name, device))
+ bdrv_commit(bs_table[i]);
}
}
}
@@ -1138,8 +1141,8 @@
static term_cmd_t term_cmds[] = {
{ "help|?", "s?", do_help,
"[cmd]", "show the help" },
-{ "commit", "", do_commit,
- "", "commit changes to the disk images (if -snapshot is used)" },
+{ "commit", "s", do_commit,
+ "device|all", "commit changes to the disk images (if -snapshot is used)" },
{ "info", "s?", do_info,
"subcommand", "show various information about the system state" },
{ "q|quit", "", do_quit,
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] What can qemu do that vmware/virtual pc can't...article idea
On Fri, 28.07.06, Udo 'Robos' Puetz <[EMAIL PROTECTED]> wrote: Hi List. I'll write this here instead of answering to each to keep the noise down :) Thanks a lot for the good ideas and comments! I'll simply collect the ideas and leave my cynical comments about lazy readers of computer magazines to myself :) (Everybody sees that qemu is waaay better than the others, why do they need to be shown? ;-) -run kernel by itself -user emulation (putty example in docs) -OSS -> independant of a company becoming bankrupt -free distributable -put on a live cd -put in a distro -can be used without the need to install anything -qemu does not need admin/root priviledges -usb tablet emulation -> no need to install vmware tools in client -can record audio (and with patch even mpegs) Thanks again for your input! Cheers Udo -- Robos - gpg --recv-keys --keyserver blackhole.pca.dfn.de 6EEADA09 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU version 0.8.2
QEMU version 0.8.2 is out. You can download it at http://bellard.org/qemu/download.html. Is there a reason there isn't a tag in CVS? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] What can qemu do that vmware/virtual pc
> Soo, do you have any more ideas what qemu can what the (free) alternatives> from M$/VMWare can't? I use both QEMU and VMWare (commercial version), but for very different reasons. Both are excellent tools that make my job easier. I'm primarily a Windows developer, but I do have some Linux tools I support. VMWare works well when I need to switch to Linux to write code. It virtualizes a generic PC, which is all I need. It's time tested, reliable and predictable. But I work for a company that sells HW/SW. Our HW is your basic PC, but with some additional non-standard devices. Our SW won't run without these devices (no way, no matter how clever you are with the preprocessor, you won't make it run). So it won't run under VMWare, or VPC. They aren't extensible. QEMU is. Just grab the source code. Fabrice et.el. did an amazing thing with QEMU. Adding emulation for our hardware wasn't tough to do. Moving from the edit...compile...download...reboot...debug...repeat cycle to edit...compile...debug...repeat cycle is a BIG advantage for us. You just can't do that with the commercial products. And QEMU is so light weight...I can throw the whole thing on a pen drive, plug into any managers/sales/marketing/tech writers/etc. machine, and just run it. Installing VMWare player is a bit more heavy handed. Not sure, but I suspect you need admin priv. to do it? I live in corp. America. Our tech writers don't HAVE admin privileges. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] What can qemu do that vmware/virtual pc can't...article idea
It seems to me you missed the most important qemu feature. That is qemu will emulate different processors. Just try running an PPC version of Linux on an x86 with VMWARE. To my knowledge the only other programs that can do this are either very expensive or extremely slow. BillOn 7/28/06, Udo 'Robos' Puetz <[EMAIL PROTECTED]> wrote: Hi List.I'm in contact with one of the writers for the german (large) computermagazine c't (computer and technology) defending qemu (he neglected somefeatures qemu has in one of his articles). Now he asks me for an article about what the "average user" would benefit from when he would use qemu insteadof virtual pc/vmware (their "free" products, like player, ESX ...). Theexamples I named up to now whereqemu -nographic -hda linux.img -kernel linux-2.6.17.6/arch/i386/boot/bzImage-append "console=ttyS0root=/dev/hda ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe" -hdbfat:/mnt/data/Projekte/qemu/linux-test/bladoing a little linux kernel driver development learning this way. (Good free pdf over at oreilly)Also, when testing OCFS2 (Oracle cluster fs 2) and not having a SAN/iSCSIsystem at hand I tried this:qemu -hda breezy.img -hdb ocsf2.imgmounting that image onceqemu -hda breezy.img -hdb ocsf2.imgand now mounting it again in a second instance of qemu with slightlydifferent network setup. That works with qemu, vmware desktop wouldn't takethe image a second time.Also, a demonstration LiveCD could be made to boot on a system but also to be played with qemu/qvm86 under win and linux (kqemu can't be re-distributed).There would be statically built qemu's on the CD with bat/bash skripts tostart them (automatically).Also, qemu can run happily on the server awaiting connects via vnc. But some of the free products can do that too.Soo, do you have any more ideas what qemu can what the (free) alternativesfrom M$/VMWare can't?Virtual PC can't handle USB _at_all_, what's the status of USB2.0 with qemu ( I think VMWare is still stuck on USB 1.1 )?VMWare Desktop (not free) has "unlimited" snapshots IIRC, ESX just recentlygot one snapshot functionality.I can't say if I would do the article or the writer for the magazine but at least it would make qemu more visible to (more technical inclined) people ->good in my eyes.Thanks for your suggestionsCheersUdo--Robos -gpg --recv-keys --keyserver blackhole.pca.dfn.de 6EEADA09___Qemu-devel mailing listQemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
