- Devel - libvirt List Archives

[Libvir] plans to support vde_switch ?
by adrian.lambeck＠basicsedv.de 27 Apr '07

27 Apr '07

Hello everybody, I am working on a project where I found vde_switch (http://vde.sourceforge.net/) very useful. It is based on uml_switch from the UML project. Are there any plans to support it in libvirt? Thanks. Adrian

3 2

[Libvir] about domctl
by Atsushi SAKAI 27 Apr '07

27 Apr '07

Hi, Dan I have a question about domctl(Xen hypervisor call). It seems not working on Fedora7(i386). But sysctl works fine. for example "virsh setmem" does not set memory. "virsh vcpuinfo " shows following message on dom0 (strange) VCPU: 0 CPU: 0 State: blocked CPU time: 0.0s CPU Affinity: - Would you investigate this issue? I look around the code but it should be works. Thanks Atsushi SAKAI

2 3

[Libvir] [FYI] Holidays of Japan
by Atsushi SAKAI 26 Apr '07

26 Apr '07

Next week Japan has many national holidays.(Apr 29, May 3, 4, 5) http://en.wikipedia.org/wiki/Holidays_of_Japan Someone appeared on May 1 and 2 Thanks Atsushi SAKAI

2 1

[Libvir] Remote patch, 2007-04-26
by Richard W.M. Jones 26 Apr '07

26 Apr '07

Been on holiday last week, and then got massively sidetracked with query strings in libxml2, so there's not been much progress. Nevertheless, here is the current remote patch. It still needs GnuTLS support to be copied over from the old version, so currently it only listens on Unix sockets. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

1 0

[Libvir] [PATCH][RFC] Adding Cloning Feature
by Kazuki Mizushima 25 Apr '07

25 Apr '07

Hi all, I've been planing to adding cloning feature. Then, I tried to make the patch in the following way. 1)Get the XML used virDomainGetXMLDesc 2)Delete <uuid>, <mac> node element This intened to automatically generated. 3)Changing <name>, <source dev> string node element 4)Fork "dd" process 5)Define XML used virDomainDefineXML This feature is just a first revision, because I make this patch within current libvirt API limitation. Also Remote Cloining is Limited. But if we can libvirtd for feature, it will be enhance remote cloning based on this pach (as http://libvirt.org/remote.html#Remote_libvirtd_configuration) Finally, to have to communicate with the demon remotely as libvirt library, actually I want to put down to new libvirt API (e.g. virDomainClone). Could you hear your comments about this ? Attached patch shows below. --------------------------------------------- # ./virsh --help clone NAME clone - clone a domain SYNOPSIS virsh clone <domain> <devices,...> DESCRIPTION Clone a domain. OPTIONS <domain> shut off state domain name <devices> destination devices (comma separated) # ./virsh clone PV_RH5 /dev/sdb2 Cloning from /dev/sda5 to /dev/sdb2 ..... # ./virsh list --all Id Name State ---------------------------------- 0 Domain-0 running - PV_RH5 shut off - PV_RH5_CLONE shut off #./virsh start PV_RH5_CLONE Domain PV_RH5_CLONE started --------------------------------------------- Thanks, Kazuki Mizushima

4 9

Re: [Libvir] [PATCH][RFC] Adding Cloning Feature
by Kazuki Mizushima 25 Apr '07

25 Apr '07

Hi Rich, > I think cloning is a great feature. From when I used to sysadmin a Xen > server, I used cloning as the main technique to create new servers - ie. > take an existing machine which is similar to the new one which I want, > and just clone it. Thank you for your comments and agreement. > There is no problem with interaction with the remote patch. Nor do you > have to worry about the remote stuff when implementing this (the "dd" > will fork on the remote libvirtd automagically). O.K. I understood it. I warry about remote support for libvirt architecture always. > So the idea is that you can only clone an inactive domain? This first revision, only inactive domain. But next step, I think snapshot command will be able to used instead of "dd". Thanks, Kazuki Mizushima

2 1

[Libvir] Capabilities XML format
by Mark McLoughlin 23 Apr '07

23 Apr '07

Hey, Just a few brief comments after using it: - <os_type>xen<os_type> is equivalent to <os><type>linux</type></os>, which is pretty confusing. Sounds to me like we should deprecate the latter and move to "xen" everywhere for this. - We have <host><arch>x86_64</arch></host> and <guest><arch name="x86_64"/></guest>. I can see why we did that, but it seems odd to me to have different syntaxes for <arch> depending on its context. - I'm not sure how interesting the stuff in <guest><arch> is ... how were we envisaging these bits being used? - It's a pain to have to parse XML to discover whether e.g. you can run a 64 bit guest. I'd much prefer to see the kind of API I'm using here: http://www.gnome.org/~markmc/code/test-caps.py e.g. caps = cnx.getCapabilities() supports_x86_64 = False for guest in caps.guests: if guest.arch == "x86_64": supports_x86_64 = True Cheers, Mark.

2 2

[Libvir] [RFC] Life-cycle Management of the domain
by Saori Fukuta 23 Apr '07

23 Apr '07

Hi all, I've been thinking about a way to change the hardware allocation on the Life-cycle. And I have some idea. Can I hear your comments about this? 1. Necessity of function These are conceivable cases of changing hardware allocation. CASE A: Dynamic change change the allocation dynamically -> change the hardware allocation for now, and next time, start by the allocation before it changes. (example of use) At night, change the hardware allocation. Next morning rebooting, return it. CASE B: Static change change the allocation statically -> do not change the hardware allocation for now, but set the allocation for starting next. (example of use) Next time, want to start by the value that set before. CASE C: Permanent change change the allocation permanently -> change the hardware allocation, and start next time with the same setting. (example of use) want to start by same value permanently. The current situation of virsh command with Xen. CASE A / CASE B / CASE C virsh setmem x x o virsh setmaxmem x x o virsh setvcpus o x x virsh vcpupin o x x And I find that the value on Xenstore is used for starting the domain next time. 2. Change of command We need to add 3 options to the virsh command of changing allocation for CASE A, B, and C. So I propose the following options. option name --dynamic ... dynamic change option (default) for CASE A --static ... static change option for CASE B --perm ... permanent change option for CASE C If no option is specified, the Default option("--dynamic") will be chosen. (example) Example of changing the memory allocation 256MB to 512MB. # virsh dominfo Domain-A | grep "Used memory" Used memory: 256000 kB CASE A: Dynamic change # virsh setmem Domain-A 512000 or # virsh setmem Domain-A 512000 --dynamic # virsh dominfo Domain-A | grep "Used memory" Used memory: 512000 kB CASE B: Static change # virsh setmem Domain-A 512000 --static # virsh dominfo Domain-A | grep "Used memory" Used memory: 256000 kB CASE C: Permanent change # virsh setmem Domain-A 512000 --perm # virsh dominfo Domain-A | grep "Used memory" Used memory: 512000 kB 3. Summary of the ways Xen does not provide these cases. So I propose that we start the domain by a file for libvirt. 3.1 When starting the domain first time, copy a file from config.sxp(/etc/xen config file) to virt.sxp(libvirt). (image) +--- Xend ---+ +-- libvirt --+ +--------+ l config.sxp -------> virt.sxp l +--------+ lDomain-Al +------------+ copy +-------------+ lDomain-Al lmem=256 l lmem=256 l +--------+ ----------------------------------> +--------+ "virsh start Domain-A" 3.2 When starting the domain, if they have virt.sxp(libvirt) define that file. (image) Step.1 value of the domain before start. +--- Xend --------------------+ l +-Xenstore-+ +-config.sxp-+ l before l l mem=256 l l mem=256 l l +--------+ l +----------+ +------------+ l lDomain-Al +-----------------------------+ lmem=256 l +--------+ ---------------------------------> continue Step.2 Step.2 define the value of virt.sxp. +--- Xend ---------------------+ l +-Xenstore-+ +-config.sxp-+ l +----> mem=512 l -> mem=512 l l define l l +----------+ +------------+ l l +------------------------------+ l +--- l --------+ l +- l --------+ before l l mem=512 l l +--------+ l +-virt.sxp-+ l lDomain-Al +--- libvirt --+ lmem=256 l +--------+ ---------------------------------> continue Step.3 Step.3 start the domain and copy a file from config.sxp to virt.sxp. +--- Xend ---------------------+ l +-Xenstore-+ +-config.sxp-+ l l l mem=512 l l mem=512 l l l +--- l ----+ +----- l ----+ l +----- l ------------- l ------+ l l +--- libvirt --+ l l copy l +-virt.sxp-+ l l +-------------> mem=256 l l before l l +----------+ l +--------+ l start +--------+ +--------------+ lDomain-Al +------------>lDomain-Al lmem=256 l lmem=512 l +--------+ -------------------> +--------+ "virsh start Domain-A" 3.3 When changing the allocation statically or permanently, write the change into virt.sxp. (When changing the allocation dynamically, do nothing) CASE A: Dynamic change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=512 l l mem=512 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=256 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=512 l ll lmem=256 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000" ll (state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=Y, mem=Y mem=X(no change) mem X to Y dynamically 3.stop the domain mem=Y, mem=Y mem=X 4.start the domain <------- <-----------define value mem=X, mem=X --->mem=X(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+ CASE B: Static change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=256 l l mem=256 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=512 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=256 l ll lmem=512 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000 --static" ll (state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=X, mem=Y mem=Y(change to Y) mem X to Y statically 3.stop the domain mem=X, mem=X mem=Y 4.start the domain <------- <-----------define value mem=Y, mem=Y --->mem=Y(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+ CASE C: Permanent change (image) +--- Xend --------------------+ ll next start l +-Xenstore-+ +-config.sxp-+ l ll l l mem=512 l l mem=512 l l ll l +----------+ +------------+ l ll +-----------------------------+ ll +--- libvirt --+ ll l +-virt.sxp-+ l ll before l l mem=512 l l after ll +--------+ l +----------+ l +--------+ ll +--------+ lDomain-Al +--------------+ lDomain-Al ll lDomain-Al lmem=256 l lmem=512 l ll lmem=512 l +--------+ -------------------------------> +--------+ ll +--------+ "virsh setmem Domain-A 512000 --perm" ll (state transition matrix) +-------------------------------------------------------------+ operational procedure Xend libvirt Xenstore config.sxp virt.sxp +-------------------------------------------------------------+ 1.start the domain mem=X, mem=X --->mem=X(create file) 2.change the allocation mem=Y, mem=Y mem=Y(change to Y) mem X to Y permanently 3.stop the domain mem=Y, mem=Y mem=Y 4.start the domain <------- <-----------define value mem=Y, mem=Y --->mem=Y(create file) 5.delete the domain del del delete file +-------------------------------------------------------------+ Thanks, Saori Fukuta

3 8

[Libvir] Remote & the problem with qemu deadlock
by Richard W.M. Jones 19 Apr '07

19 Apr '07

As I wrote here: https://www.redhat.com/archives/libvir-list/2007-April/msg00114.html remote access to qemu:/// URLs currently deadlocks. A bit of explanation follows as to why this happens in the current architecture of the remote patch. If you apply the remote patch right now, you'll get a modified libvirt_qemud server which can handle both qemu and remote requests over the same socket. (Basically both qemu_internal.c and remote_internal.c connect to the same Unix domain socket, then depending on the "program number" encoded within the RPC messages, they get dispatched accordingly inside libvirt_qemud). The server is written to handle multiple connections at once using non-blocking poll[1], but once the server has assembled a whole incoming message, it then blocks while dealing with that message. The problem occurs in the qemu case when the remote server issues a call into qemu_internal (now linked into the server), and qemu_internal then tries to connect out to the qemu daemon. Unfortunately the qemu daemon /is/ the remote server, which is blocked handling the current call. Thus it is unable to accept the new connection (from itself) and completely deadlocks. One solution suggested was to have qemu_internal recognise when it is linked into the server and make local calls back to its counterpart in the server. However I think this is pretty ugly and unnecessarily complicates qemu_internal which shouldn't care how it is linked. My thoughts on the long term solution ------------------------------------- I'd really like to see the qemu case not require a daemon. At the moment (AFAICS) the qemu daemon serves two purposes: (a) it keeps track of the monitor file descriptors of the existing qemu processes, and (b) it handles the networking stuff, basically starting and stopping dnsmasq[2]. (a) is easily handled, I think, by having qemu processes put their monitor sockets into a well-known directory. This has the other advantage that qemu processes can survive and continue after qemu programs restart. For the (b) case, I don't think networking which is a general service should be mixed up with qemu code. I think (although probably I've missed some things) that this means that qemu_internal could be implemented entirely as a local service, requiring no daemon. (In the case where qemu_internal needs to control a root-owned system-wide set of qemu processes then we'd still have to have a daemon, but it can be the remote daemon, same way that Xen will work). My suggestion for a short term solution --------------------------------------- Since doing the above is way more than I'm going to do just to get remote working, my suggestion is that we have two daemons running, qemud and remote. Both would be built from the exact same codebase: the mode would be selected by having a 'libvirtd --remote' flag on the command line (or however, but the important thing is that they'd keep the same codebase). This immediately fixes the deadlock problem[3] because qemu_internal linked to the server is now talking to a different daemon. Rich. [1] As an aside, I don't particularly like this architecture. Linus has handed down to us an efficient operating system which is already capable of multiplexing different clients using a marvellous system called "multitasking". Hand-coding polling code inside a single process is really only necessary in very limited circumstances, such as highly tuned uniprocessor machines with enormous loads, and we are not likely to get into such a situation with libvirtd. If we ever did we'd need to benchmark a range of possible solutions. Processes on the other hand have real advantages, such as security through isolation and controlled sharing, and easy scalability onto SMP machines. [2] Although I don't really understand the networking stuff too well, so perhaps it does other things. [3] Except in the "remote-on-remote" case, but we should disallow this explicitly because it seems like it would be nothing but trouble. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)

2 4

[Libvir] Community IRC chat room for virt management tools/APIs/protocols
by Daniel P. Berrange 19 Apr '07

19 Apr '07

At the Xen summit a number of us thought it would be a good idea to have an IRC chat room for people interested in technical discussions relating to hypervisor agnostic management tools / APIs / protocols. This includes libvirt, virt-manager, VNC extensions for virtualization, and more. Thus we decided to colonise the channel #virt on irc.oftc.net - feel free to come and join us.... Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0