Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
Daniel P. Berrange wrote: > > Much better to exact a commitment from libvirt to track all QMP (and > > command line) capabilities. Instead of adding cleverness to QMP, add > > APIs to libvirt. > > Agreed. Despite adding this monitor / XML passthrough capability, we still > do not want apps to be using this at all. If there is some capability > missing that apps need then the default mode of operation is to add the > neccessary bits of libvirt. The monitor/XML pasthrough is just a short > term quick workaround until the official support is done. As such I do > not really think we need to put huge amounts of effort in the wierd > complex racey edge cases. The effort is better spent on getting the > features in libvirt. All the features? The qemu API is quite large already (look at all the command line options and monitor commands). I'll be very surprised if libvirt provides all of it that obscure apps may use. I'm thinking of features which are relatively obscure but nonetheless useful to a small number of deployments. Probably not enough to justify the effort building data models, specifying the XML and remote protocol and so on in libvirt. (Unless that becomes so easily mapped to qemu's API that it's almost an automatic thing... Which sounds like QMP, doesn't it?) Is libvirt ever likely to go to the effort of providing all the easily-usable API, or hooks, for: - sending keys to a guest, driven by a timed host script? - rebooting the guest while switching between USB touchpad and mouse devices, because one of them is needed during an OS install and the other is needed after? - changing the amount of RAM available to the guest at the next reboot, for OS install needing more memory than run time, in a scripted fashion when building new VMs from install disk images? - switching the guest between qemu mode and kvm mode on the next guest reset, because qemu is faster for some things (VGA updates) and kvm is faster for other things, so the best choice depends on which app you need to run on that guest - pausing a VM, making a copy, and resuming it, so as to fork it into two VMs (literally fork)? - setting up the host network container and NAT IP forwarding, on demand as guests are stopped and started, so that it works in the above scenario despite clashing IP addresses? - running a copy of the same guest, or perhaps an entire OS install process (scripted), many times for different qemu and qemu-kvm versions, different BIOSes, and different almost-equivalent hardware emulations (i.e. different NIC types, SMP count, CPU features, disk controller type, AIO/cache type) - for testing guests and apps on them - with some paralellism? None of those, except perhaps the first, as what I think of as typical virtualisation workloads, and they all seem obscure things probably outside libvirt's remit. Probably not many users either :-) Yet you can do them all today with qemu and scripting the monitor, and it's getting easier with QMP. Which is fine, qemu works, but it would be great to be able to see those guests and interact in the basic ways through the libvirt-based GUIs? QMP pass-through or QMP multiple monitors seems to provide most of that, although I can see libvirt getting a bit confused about which devices and how much RAM the guest has installed at different times. The bit about forking guests, I'm not sure how complicated it is to tie in to libvirt's notion of which disk images are being used, and hooking into it's network configuration to handle the clashing addresses. If those things are considered to be entirely outside libvirt's remit, that's fine with me. Fair enough: I will continue to live with ssh and vinagre. I'm just raising my hand as a potential user who might like to monitor a bunch of active and inactive guests, remotely, see how much memory they report using, etc. launch VNC viewer from the GUI, even choose the target host based on load and migrate on demand, while also needing a fair bit of non-standardness and qemu-level scripting too. Imho, that probably comes under the heading of apps using pass-through or multiple QMP monitors, which use features that probably won't and probably shouldn't ever be handled by libvirt itself. -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
Daniel Veillard wrote: > On Sun, Apr 11, 2010 at 11:17:38PM +0100, Jamie Lokier wrote: > > It's not that hard to write this for trivial extra options: > > > >/bin/sh -c 'qemu "$0" "$@" -extra-flag' > > > > (if that works). > > That won't work because we expect the emulator to be a path to > the emulator program, so yes that has to be done in the wrapper script. Ok. Being able to pass arguments would be about infinitely more useful, so that you don't need a separate wrapper script for every individual guest configuration - you can pass options to the single wrapper for each variation. Even /path/to/wrapper qemu-0.11 is a big improvement over /path/to/wrapper-guest-config-6-with-qemu-0.11 ;-) Some simple but versatile hook ideas: - (no space splitting, one option, appended) - (space splitting multiple options) - - - VALUE - /path/to/script This last one is to call the script, but pass all the options including the path to whichever version of qemu/kvm would get selected by libvirt. (I presume it has some selection mechanism, given the variety of guests which break with each version of qemu and/or qemu-kvm and/or kvm?) (It is most unfortunate that XML forces those long prefixes everywhere due to lack of contextual naming, unlike less verbose config formats :-/) > > Parsing libvirt output and having to guess which option corresponds to > > what from the libvirt config sounds very fragile and also a rather > > large amount of effort for something which should be easy. > > it's not that easy because we change the way we build the command line > for qemu as qemu evolves. for example before and after the support for > -device there have been a lot of changes. I agree, which is why it's much less fragile if libvirt provides the individual parts to hooks/wrappers, if that's asked, rather than forcing the wrapper to parse libvirts output and guess what libvirt does from version to version. For sure, before and after -device, any script which is involved with those options will probably have to change. But that's quite unusual. Most usually I'd expect things like the order of -device options might change depending on how libvirt pulled together it's backing resources, for example. -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
Richard W.M. Jones wrote: > On Fri, Apr 09, 2010 at 10:06:51PM +0100, Jamie Lokier wrote: > > Daniel P. Berrange wrote: > > > I think this alteration of existing args is fr too complex & fragile, > > > and way overkill. > > > > Would it not be simpler, for the target audience, for the config to > > contain a one-line shell script to transform particular matched > > arguments in any way that's wanted? > > I might be missing something but I thought you could already do this > in current libvirt. ie. Change the element [1] to point to > your shell script: > > /usr/local/bin/my-qemu-wrapper.sh > > The wrapper should get called with the command line arguments and you > can alter them however you like. > > Isn't that right, Dan? That forces the shell script to be relatively complicated and recognise all qemu arguments (including version specific ones) to skip the ones with parameters - and to know where to look for the real target executable is. It's not a very friendly way to add or change parts of specific subsystems, for example modifying a blockdev parameter, but it can be done that way if necessary. It's not that hard to write this for trivial extra options: /bin/sh -c 'qemu "$0" "$@" -extra-flag' (if that works). But for things like modifications to particular devices, wouldn't it be better to associate "add cache=special option" to a section about one of the blockdevs which libvirt knows about, rather than the awful prospect of parsing libvirt's output to guess which of three -device arguments corresponds with the second SCSI drive mentioned in the libvirt config - which might not necessarily be the second on the command line, even. Parsing libvirt output and having to guess which option corresponds to what from the libvirt config sounds very fragile and also a rather large amount of effort for something which should be easy. And then there's modifying how network tap devices are set up and other networking, outside qemu, but requested by libvirt. Doing that in sounds like a bad idea, but script hooks are the only sane way to make networking fit every environment and requirement. Ideally without forcing the hook writer to reimplement the normal network setup from scratch just to tweak it a bit. I apologise if libvirt already provides such hooks - I haven't looked at that part of it. -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
Daniel P. Berrange wrote: > I think this alteration of existing args is fr too complex & fragile, > and way overkill. Would it not be simpler, for the target audience, for the config to contain a one-line shell script to transform particular matched arguments in any way that's wanted? > If the arg that libvirt generates isn't what someone > needs, then remove the bit of the guest config responsible for that and > add a complete extra arg, rather than munging the existing one. Problem with that: You might want libvirt to think it has a device that it's controlling, still show in the GUI, still tie up with the rest of the stack, still do the management setup, but you just want to change some qemu-specific parameters. For example, cache=somethingelse for block devices, iptables=tobedefined for net devices, usbimplementation=hack for USB devices. -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Supporting hypervisor specific APIs in libvirt
Avi Kivity wrote: > On 03/23/2010 09:31 PM, Anthony Liguori wrote: > > > >> > >>One problem is that this is libvirt version specific. For example, > >>libvirt x doesn't support spice so we control that thorough qmp. But > >>libvirt x+1 does support spice and now it gets confused about all the > >>spice messages. > > > >That's only a problem if we only support a single QMP session. This > >is exactly why we need to support multiple QMP sessions (and do). > > It's unrelated to the number of sessions. libvirt expects state that it > manages in qemu not to change randomly. Users know that, so they will > only manage non-libvirt state in their private session. But a new > version of libvirt may expand its scope and start managing this area, > leading to conflicts. We have events when state changes, for libvirt to be informed. But that's prone to race conditions. A fairly universal solution to that is "pre"-events, where something that's going to change state emits a pre-event, waits for an ack from all listeners, then proceeds or not according to the acks, then finally emits the post-event to say the state is changed. Between pre and post events, as far as the listener is concerned, the state is uncertain and it must query or wait when it needs the value.(*) In other words, libvirt would register to listen to all the pre-events for state that it cares about being synchronised with. When libvirt expands its scope, it would simply listen to some more. -- Jamie (*) Yes, this is like 2-phase transactions, and it's also a bit like MESI caching. But it's easier to understand than both :-) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote: > I'm not sure. The human monitor has some features that are not > appropriate for QMP. For instance, the ability to deal with formula > input and some commands meant to add debugging. > > I guess you could do that in qemu-cmd but I don't see a compelling > reason to. Would it be all that much work to just rip out the human monitor altogether, moving it's functionality to qemu-cmd? That'd be a great way to confirm that QMP has all the functionality. It doesn't have to be written in C, by the way ;-) -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote: > On 03/25/2010 09:09 AM, Luiz Capitulino wrote: > > > >>We can provide a generic QMP dispatch interface that high level > >>languages can use. Then they can do fancy dispatch, treat QErrors as > >>exceptions, etc. > >> > > They can do that by accessing QMP directly. Why would a Python developer > >get in the mess of writing a Python binding for libqemu if they call do > >the exactly same thing by using its native json module? > > > > Man, opening a QMP connection from Python and sending commands can be > >done with a few lines. > > > > Problem is, without a libqemu, libvirt cannot return a QMPContext that > can be used by python bindings. This is the problem that all high > level languages have with respect to RPC transports. > > You need libqemu to deal with establishing the transport. That code > needs to be common and shared across languages. We can't libvirt talk QMG with Python over a pipe or local socket? So that the Python can talk to native qemu and via libvirt with the same code. That would be much easier from Python person than writing a wrapper around the C library. Multiplied by each high-level language... -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote: > But the advantage is that if libvirt provided an API for a QMP transport > encapsulated in their secure protocol, then provided the plumbed that > API through their Python interface, you could use it for free in Python > without having to reinvent the wheel. It's not free if the only "free" way to access all qemu's capabilities from Python requires you to switch all your config files to libvirt's format and libvirt's way of doing things. There's quite a big jump from the qemu/kvm way of doing things and the libvirt way, and the latter isn't well matched to all uses of qemu. But if libvirt exposes the same QMP as direct to qemu, or something very similar (it could wrap it, and add it's own libvirt events, commands and properties), that would be great for scripts that could then work with either with minimal change. -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Avi Kivity wrote: > On 03/24/2010 02:32 PM, Anthony Liguori wrote: > >>You don't get a directory filled with a zillion socket files pointing > >>at dead guests. Agree that's a poor return on investment. > > > > > >Deleting it on atexit combined with flushing the whole directory at > >startup is a pretty reasonable solution to this (which is ultimately > >how the entirety of /var/run behaves). > > > >If you're really paranoid, you can fork() a helper with a shared pipe > >to implement unlink on close. > > My paranoia comes nowhere near to my dislike of forked helpers. Use clone() then, it's cheaper ;-) Anyway, Linux at least *does* have unlink-on-exit unix sockets: use the abstract unix namespace. Enumeration is a different problem from being able to connect to an instance, and there are several approaches to enumerating multiple running instances. One of the most well known at the moment is mDNS service discovery, and each instance registering with freedesktop's Avahi enumeration service. -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Alexander Graf wrote: > I don't see why we shouldn't be able to automatically generate > libqemu.so. We have the *.hx files that describe the syntax of > parameters plus list all available options / commands. I'm not sure > how exactly QMP works, but having a generic QMP command to list all > available options would be handy too. > > By then we could automate most of the library, making the glueing > really easy. If libvirt doesn't properly link against libqemu anymore > we also know why: The ABI changed. I'm thinking most potential uses of the binary API, other than C programmers, would be happier with a D-Bus version generated from those same *.hx files. Because then it's easy to call the API from Python, Perl, even shell, etc. Whereas libqemu.so would be relatively difficult to use from those languages. (Aside: I don't particularly like D-Bus. But it does seem to work for this sort of thing.) -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote: > On 03/23/2010 10:57 AM, Paul Brook wrote: > >I thought the monitor protocol *was* our API. If not, why not? > > It is. But our API is missing key components like guest enumeration. Is that simply enumerating running qemu instances, and asking each one about things like it's name, VNC port, etc.? Having each qemu publish itself through D-Bus or Avahi (to find the list of running instances), and every info query go through the monitor, would seem a clean solution to that. Are there any other missing key components? -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Juan Quintela wrote: > - monitor: I need a way to get to the monitor when going through > libvirt, in the past you couldn't allow this, but now it looks > possible. Now you can just start another monitor connection to qemu :-) Previously I've used a multiplexing script which accepts multiple monitor connections, and passes the commands to the real connection. It's not ideal because a slow command blocks any others, but it basically works. > - changing the emulator: It is normal for me to be using several qemu > binaries for testing, changing it with libvirt is just a mess. Same here, except not just for testing: I need to use different qemu binaries for production use, because newer ones don't work with some VM images that work on older ones. > - virt-viewer: I want to be able to switch consoles, period. A decent VNC client gets close to this. If the qemus advertised themselves, some VNC clients would show a list of them automatically. As it is, I use Gnome's VNC client with a bookmark for each VM, which works quite well. It even has tabs :-) > - networking: man, setting networking is a mess, libvirt just does it > for you. networking is often a mess, and what libvirt does isn't always what you want, even if it often is. I need the option to set up networking separately and have libvirt use what it's given, otherwise I cannot use it. -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Gerd Hoffmann wrote: > >- networking: man, setting networking is a mess, libvirt just does it > > for you. > > +1 > > Even when not using libvirt for a reason or another I usually hook my > virtual machines into virbr0 (libvirt default network). I had the opposite problem. Needed to use multiple bridges and have some VMs behind NAT without a bridge (private IPs), and some using separately firewalled bridges (needed to behave like real attached hardware with their original MACs, but be firewalled). I couldn't see how to do it easily with libvirt, so used qemu directly. -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote: > (like mDNS or SLP). The later mechanism scales better and tends to > be more robust. (Aside: mDNS is blocked on some larger networks because it creates too much load. On those networks, an aggregator is essential - or a protocol which scales better (less broadcasting)). Doesn't libvirt use mDNS already to discover multiple hosts on a network, for remote access? If so, why can't exactly the same protocol be used to enumerate multiple VMs on each host? If not, why not? -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Avi Kivity wrote: > If you want things to work reliably, you have to follow the chain of > command. Or use locks and/or transactions like everything else :-) -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Gerd Hoffmann wrote: > Management apps don't need new parsers, the existing "info " > parser(s) will do just fine. And QEMU doesn't need new printers. Less code to go wrong :-) -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Avi Kivity wrote: > Daniel P. Berrange wrote: > >Yes indeed its a little crazy :-) As anthony mentioned if libvirt were > >able to be notified of changes a user makes in the monitor, there's no > >reason we could not allow end users to access the monitor of a VM > >libvirt is managing. We just need to make sure libvirt doesn't miss > >changes like attaching or detaching block devices, etc, because that'll > >cause crash/data loss later when libvirt migrates or does save/restore, > >etc because it'll launch QEMU with wrong args > > > > You still have an inherent race here. > > user: plug in disk > libvirt: start migration, still without disk > qemu: libvirt, a disk has been plugged in. Then fix it. The race is not necessary. user: plug in a disk libvirt: lock VM against user changes incompatible with migration qemu: libvirt, lock granted libvirt: query for current disk state libvirt: start migration, knows about the disk The "libvirt, a disk has been plugged in" will be delivered but it's not important. libvirt queries the state of things after it acquires the lock and before it starts migration. > That means that to debug a problem in the field you have to locate a > guest's host, and follow it around as it migrates (or disable migration). That's right you do. Is there any way to debug a guest without disabling migration? I don't think there is at present, so of course you have to disable migration when you debug. Another reason for that "lock against migration" mentioned above. -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Avi Kivity wrote: > Anthony Liguori wrote: > >At the end of the day, I want to be able to run a QEMU instance from > >the command line, and have virt-manager be able to see it remotely and > >connect to it. That means multiple monitors and it means that all > >commands that change VM state must generate some sort of notification > >such that libvirt can keep track of the changing state of a VM. > > I don't think most management application authors would expose the qemu > monitor to users. It sounds like a huge risk, and for what benefit? If > there's something interesting you can do with the monitor, add it to the > management interface so people can actually use it. They don't buy this > stuff so they can telnet into the monitor. I want the same as Anthony. I want to do unusual things that libvirt doesn't support and shouldn't have to support itself, such as sending keystrokes to a running VM (from a script), attaching a debugger, and hotplugging network devices that are configured differently to how libvirt would like to do it. I also want these VMs to show in the nice GUI along with other non-debugging VMs, show their resources, start and stop them easily, catch them when they attempt to reboot, and let me do these things remotely. My solutionat the moment is to put a monitor multiplexer outside QEMU (it's a small Perl script). It accepts multiple monitor connections and forwards to QEMU's single monitor, parsing the "^\(qemu\) " prompt. This is obviously silly but it's what we have to do to get this functionality. I don't see how adding those low-level monitory things to libvirt is an improvement - debugging and scripted keystrokes are not the sort of functionality libvirt is for - or is it? The other alternative is not to use libvirt for these VMs, but that means losing functionality that's useful to me (visibility in the GUI), and more importantly it means I have to configure nearly identical VMs in a completely different way (totally different configuration syntax between libvirt and QEMU direct) depending on what I'm going to do with them. Hence multiplexing monitors, either outside or inside QEMU. Inside is better because its behaviour is more well-defined. -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
Daniel P. Berrange wrote: > One scheme would be to have a small buffer - enough to store say 10 events. > If the monitor is blocking for write, and the buffer is full then start to > discard all further events. When the buffer has more space again, then > send an explicit 'overflow' event informing the app that stuff has been > dropped from the event queue. > > In normal circumstances the app would never see this message, but if there > was some unexpected problem causing the app to not process events quickly > enough, then at least it would be able to then detect that qemu has > discarded alot of events, and re-synchronize its state by running appropriate > 'info' commands. This is pretty much what Linux real-time queued I/O signals do. It's ugly but works. :-) -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
Anthony Liguori wrote: > Paul Brook wrote: > >No you don't. If you use event flags rather than discrete events then you > >don't need to buffer at all. You just need to be able to store the state > >of each type of event you're going to raise, which should be a bounded set. > > > >This has its own set of issues - typically race conditions or "lost" > >events if the client (libvirt) code isn't written carefully, and means you > >can't attach information with an event, only indicate that something > >happened. > >However if the correct model is used (event driven polling rather than > >purely event driven) this shouldn't be problem. > > It's just deferring the problem. Consider the case of VNC user > authentication. You want to have events associated with whenever a user > connects and disconnects so you can keep track of who's been on a > virtual machine for security purposes. > > In my model, you record the last 10 minutes worth of events. If a user > aggressively connects/reconnects, you could consume a huge amount of > memory. You could further limit it by recording only a finite number of > events to combat that problem. It's not deferring the problem - it's mixing two different, slightly incompatible problems, and that means bugs. One is monitoring state of QEMU. (E.g. is the VM running, has it stopped due to ENOSPC, has the watchdog triggered, what's the current list of attached VNC and monitor clients, how's that migration going). That's a good use for event-driven polling, because that won't break no matter if a monitoring app goes to sleep for 15 minutes, disconnects and reconnects, etc. etc. The other problem is logging discrete events. For that you do need to expire things, keep a maximum number of events, probably timestamp events, and not merge equivalent events together. But that is unreliable for event-driven state monitoring. What happens if there are 1000 VNC connect/disconnect pairs in rapid succession (think client bug or open port facing the net)? If the event log has a limit of 1000 stored events, it will throw away some events before a monitoring app sees them. That app then fails to notice that the VM stopped due to ENOSPC, because that event was thrown away before the monitoring app could read it. Linux has something analogous to these two: normal signals and real-time queued signals. Normal signals are fixed-size state, and they are never lost if used properly. Real-time queued signals carry information, such as about some I/O or timer which has completed, but there's a problem which is the limited queue size. It's important to avoid losing data when the queue is full, because apps depend on deducing state from the queued events, so there's a special "queue full" signal always sent when the real-time signal queue is full. This tells apps that detailed queued data has been lost, and they need to poll everything to check the state of everything. To support state-monitoring apps (e.g. one which says if the VM is still running :-), you mustn't discard the "VM has stopped" events no matter how many times that or other events are sent. But you can merge them into a single pending state. To support looking at recent VNC connections, you do need a limit on the number of stored events, discard when the limit is reached, and not to merge them. One way to make both of these work is to have a "some events have been discarded here" event. At least state-monitoring apps can see that means they should poll all the state again. It's not ideal though, if that happens often. -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Avi Kivity wrote: > I'm not sure I understand your questions. Multiple monitor sessions are > like multiple shell sessions. I don't think a control program should > use more than one session, but it should allow a developer to connect to > issue 'info registers' and 'x/20i' commands. Of course if a developer > issues 'quit' or a hotunplug command, things will break. In most cases I think commands like 'stop' or a hotunplug command shouldn't break libvirt or other control program. As long as there's a way for libvirt to query the current hotplug state and be notified of changes, why shouldn't it behave much the same as if you asked libvirt to do do the same action itself? -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Avi Kivity wrote: > >I think the thing that is missing is that the 'wait' command does not > >have to be part of the non-human mode. In non-human mode, you are > >always doing an implicit wait. > > I think 'wait' is unusable for humans. If I want qemu to tell me > something happened, it's enough to enable notifications. There's no > need to tell it to wait every time something happens. That's poll(2), > there's no poll(1). For some purposes I'd prefer 'wait' on a separate monitor. For the same reason that we sometimes redirect the output of background shell commands to a file :-) Solution: 'wait -background' for those async notifications. Or simply 'notify -background event-type', no need for a wait command if you give that option. Or conversely 'notify -channel 1 event-type' to direct the events to channel 1, and 'wait -channel 1' to show events on that channel. -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
Anthony Liguori wrote: > It doesn't. When an app enables events, we would start queuing them, > but if it didn't consume them in a timely manner (or at all), we would > start leaking memory badly. > > We want to be robust even in the face of poorly written management > apps/scripts so we need some expiration function too. What happens when an app stops reading the monitor channel for a little while, and there's enough monitor output to fill TCP buffers or terminal buffers? Does it block QEMU? Does QEMU drop arbitrary bytes from the stream, corrupting the output syntax? If you send events only to the monitor which requests them, then you could say that they are sent immediately to that monitor, and if the app stops reading the monitor, whatever normally happens when it stops reading happens to these events. In other words, no need for arbitrary expiration time. Makes it determinstic at least. > >>And then in the 2nd monitor channel, a single 'wait' command would turn > >>off the monitor prompt and make the channel dedicated for just events, > >>one per line > >> > >> (qemu) wait > >> rtc-change UTC+0100 > >> vnc-client connect 192.46.12.4:9353 > >> vnc-client disconnect 192.46.12.4:9353 > >> vnc-client connect 192.46.12.2:9353 > >> vnc-client disconnect 192.46.12.2:9353 > > > >IMHO this is more useful than having "wait" just get one event. > >You'll need a dedicated monitor channel for events anyway, so with > >one-event-per-wait the management app would have to issue wait in a loop. > > There two issues with this syntax. The first is that 'notify EVENT' > logically acts on the global event set. That's not necessarily what you > want. For instance, libvirt may attach to a monitor and issue a 'wait > "vm-state vnc-events"' and I may have some wiz-bang app that wants to > connect on another monitor, and issue a 'wait "watchdog-events"'. My > super-deluxe app may sit watching for watchdog events to do some sort of > fancy RAS stuff or something like that. I like this idea a lot. Specifically I like the idea that separate monitoring apps can operate independently, even watching the same events if they need to. A natural way to support that is per-monitor (connection?) event sets. To reliably track state, monitoring apps which aren't in control of the VM themselves (just monitoring) will need to do this: 1. Request events. 2. _Then_ check the current state of things they care about. (E.g. is the VM running) 3. _Then_ listen for new events since step 1. Otherwise you get races similar to those signal/select races. That argues for (qemu) notify event-type-list ok (qemu) query blah blah... results (qemu) wait Rather than (qemu) wait event-type-list As the latter form cannot accomodate a race-free monitoring pattern unless you have a second connection which does the state query after the first "wait" has been issued. It would be silly to force monitoring apps to open two monitor connections just to view some state of QEMU, when one is enough. Also, the latter form (wait event-type-list) _must_ output something like "ok, events follow" after it has registered for the events, otherwise a monitoring app does not know when it's safe to query state on a second connection to avoid races. > The 'notify EVENT' model makes this difficult unless you have notify act > only on the current monitor session. That would be nice! > Monitor "sessions" are ill-defined > though b/c of things like tcp:// reconnects so I wouldn't want to do that. Oh dear. Is defining it insurmountable? Why can't each TCP (re)connection be a new monitor? > >BTW: "wait" is quite generic. Maybe we should name the commands > >notify-*, i.e. have > > Good point, I like wait_event personally. Me too. And request_event, rather than notify. And a way to remove items from the event set. -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
Paul Brook wrote: > I'm extremely sceptical of anything that claims to need a fine > grained version number. In practice version numbers for open source > projects are fairly arbitrary and meaningless because almost > everyone has their own set of patches and backported fixes anyway. I find it's needed onlyh when you need to interact with a program and workaround bugs or temporarily broken features, and also when the program gives no other way to determine its features. For some reason, I find kernels are the main thing this matters for... If the help text, some other output, or an API gives enough information for interacting programs to know what to do, that's much better and works with arbitrary patches etc. -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
Anthony Liguori wrote: > I still think libvirt should work with versions of QEMU/KVM built from > svn/git though. I think the only way to do that is for libvirt to relax > their version checks to accommodate suffixes in the form > major.minor.stable-foo. Ok, but try to stick to a well-defined rule about what suffix means "later" or "earlier". In package managers, "1.2.3-rc1" is typically seen as a later version than "1.2.3" purely due to syntax. If you're consistently meaning "0.11.0-rc1" is earlier than "0.11.0" (final), that might need to be encoded in libvirt and other wrappers, if they have any fine-grained version sensistivity such as command line changes or bug workarounds. The Linux kernel was guilty of mixing up later and earlier version suffixes like this. With Linux this is a bit more important because it changes a lot between versions, so some apps do need fine-grained version checks to workaround bugs or avoid buggy features. Maybe that won't even happen with QEMU and libvirt working together. -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [et-mgmt-tools] Re: [libvirt] RE: [Qemu-devel] [ANNOUNCE] virt-mem tools version 0.2.8 released
Javier Guerra wrote: > On Thu, Aug 7, 2008 at 8:06 AM, Richard W.M. Jones <[EMAIL PROTECTED]> wrote: > > I think the message here is, install libvirt & be happy :-) > > nice as this tool sounds, i would need far more than this to make me > switch from a simple, easily scriptable command-line to a generic, > 'lowest common', solution like libvirt. > > of course, i hope it keeps getting better. who knows? maybe in a year > or so it would be comparable to the CLI. Regrettably I agree for the moment. I ended up writing a Perl management script for my KVM VMs because libvirt was just too muddled and limited for my needs, and because the config file format confused me, didn't handle everything I needed, and I didn't find clear documentation on it. Also, I wanted to import existing guests from another VM, and libvirt's tools seemed strongly geared around creating new VMs to use with libvirt. So I had to write config files for it - see above. I like the idea of libvirt a lot and wish it well. My own Perl script was a nightmare to write even though it's not so long (synchronisation & monitor issues especially), so I respect what's done. It's a good goal. But I just found it too confusing to use in the ways I needed to use KVM, that I gave up on libvirt for now rather than spend the considerable time to get to grips with what it's doing, and it's config format. What would be nicer is a VM management protocol build in to QEMU, KVM and XEN, which is a bit like the monitor, but supports multiple client connections and overlapping operations (where reasonable), and is a bit more structured, so e.g. you can get the state of anything whose state you can set, you can wait for events, etc. The somewhat object-based config file work that's been discussed not long ago would be a good thing to structure it around. -- Jamie -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
