Re: [libvirt] VMware ESX driver announcement
Daniel Veillard wrote: The other possibility was to use the libraries they provide to interconnect, but there was a licencing problem, plus you can't expect to have thing installed on the server, so this was a dead end too. We looked at this closed source communication library provided by VMware too, but dropped it because of the licensing problems. Yup, too bad, I'm pretty sure it does most of what you're doing now and even use libxml2 for doing so too. By not open sourcing it this means double effort ... Did anyone made an attempt to get it 'free' via the open-vm-tools guys? Becaues I find it hard to believe VMware starts an open source project on one side and doesn't want to help on the other one. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeNodeMemory
Gihan Munasinghe wrote: Hi Is there a specific reason for not having a free_memory with in the virNodeInfo structure. I can see there is virNodeGetFreeMemory(connection) which currently not implemented for XEN.. I can add the patch to do this.. But I would like to clarify why we have not add free_memory in to the virNodeInfo structure.. Are you talking about free memory in dom 0 or the free memory on the system itself? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeNodeMemory
Daniel P. Berrange wrote: On Fri, Feb 06, 2009 at 12:15:02PM +0100, Stefan de Konink wrote: Daniel P. Berrange wrote: On Fri, Feb 06, 2009 at 09:53:04AM +, Gihan Munasinghe wrote: Is there a specific reason for not having a free_memory with in the virNodeInfo structure. All public structures are part of the public ABI and channot be changed once added. In that case, when do you consider a .so bump an option? Never. So to put it bundly, then you have much confidence in your design skills if you never allow structures to be extended. What is wrong with releasing a new version of the API having these structures added, and deprecated logic/macro's for the functions that access them? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FreeNodeMemory
Daniel P. Berrange wrote: On Fri, Feb 06, 2009 at 09:53:04AM +, Gihan Munasinghe wrote: Is there a specific reason for not having a free_memory with in the virNodeInfo structure. All public structures are part of the public ABI and channot be changed once added. In that case, when do you consider a .so bump an option? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virDomainInterfaceStats why is there a size?
Richard W.M. Jones wrote: On Tue, Aug 12, 2008 at 01:55:26PM +0200, Stefan de Konink wrote: Another simple question, what is the reasoning about the size field in this call. I would really be a happy boy if anyone said: if you put in path == NULL, it will fill your stats structure up to size interfaces. ...but since this is not the case (yet) what is the reason behind it? Sorry, I've only just noticed this question coming up. Thanks for answering anyway :) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] New Libvirt Implementation - OpenNebula
Last time *your* argument was that the API would get too big. Now why isn't that argument valid anymore? I'm honestly asking for an explanation on this point, and I do expect you have it. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] New Libvirt Implementation - OpenNebula
Daniel P. Berrange wrote: On Tue, Nov 04, 2008 at 05:04:50PM +0100, Stefan de Konink wrote: Last time *your* argument was that the API would get too big. Now why isn't that argument valid anymore? I'm honestly asking for an explanation on this point, and I do expect you have it. You are confusing internal API with external API. The external API has scalability issues because it is a long term supported ABI. The internal API size is irrelevant because we can will change that at will. The domain XML handling API is internal only for in-tree drivers. So there has been no change in policy wrt to the external API Is an external tool able to use the internal XML handling (from a C perspective?) or isn't this code exported to the shared library? Stefan ps. Sorry if you thought I was trying to virtualize a troll. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] New Libvirt Implementation - OpenNebula
Daniel P. Berrange wrote: When you update to work with latest CVS, I'd strongly recommend you make use of the brand new XML handling APIs we have in domain_conf.h. We have switched all drivers over to use these shared internal APIs for parsing the domain XML schema, so it would let you delete 90% of your one_conf.c file. It is great(!) to see that someone actually started to care about this; but honestly requests for these things were before blundly rejected. See: Comfortable lookup functions interface/block stats Could someone elaborate why after 5 months I can tag this project as 'suddenbreakoutofcommonsense'? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] Domain events - primary implementation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Daniel P. Berrange schreef:
+typedef enum {
+ VIR_DOMAIN_EVENT_ADDED,
+ VIR_DOMAIN_EVENT_REMOVED,
+ VIR_DOMAIN_EVENT_STARTED,
+ VIR_DOMAIN_EVENT_SUSPENDED,
+ VIR_DOMAIN_EVENT_RESUMED,
+ VIR_DOMAIN_EVENT_STOPPED,
+ VIR_DOMAIN_EVENT_SAVED,
+ VIR_DOMAIN_EVENT_RESTORED,
+} virDomainEventType;
Is it possible to get an *active* migration state event from the source.
In xm list the name seems to change to migrating-.
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREKAAYFAkjuTmkACgkQYH1+F2Rqwn35vACaAjyvkk8A26xEpwRZErxUIYa+
jUsAn12ekFAZLNI9EQc9p1xvL0WdnHB4
=TsbX
-END PGP SIGNATURE-
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Xen Migration does not work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Richard W.M. Jones schreef: On Mon, Oct 06, 2008 at 03:29:46AM +0200, Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm try to migrate using libvirt: virsh # migrate 0802367323_PIQ002 xen://xen002.local/ libvir: Xen Daemon error : POST operation failed: xend_post: error from xen daemon: (xend.err 'Missing parameter: node') Looks like the latest version of Xen adds yet another required migration parameter. Luckily it seems like older Xen should ignore unneeded parameters.. so does this work? I didn't test it but from what I read in the new code, is the form function checks if specific parameters are available. Not if others are explicitly unavailable ;) So I'm a happy user now by patching libvirt. (If you could comment on my other question of this week about the actual implementation of using virMigrate, would be appreciated) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjs2wQACgkQYH1+F2Rqwn07xQCfYqmOCdL6NWmNO3c/cHAg8ul9 rtUAniGJzTvznUenAzBdYDTM5nlu1G4w =3YQ7 -END PGP SIGNATURE- --- src/xend_internal.c.old 2008-09-22 15:12:12.0 +0200 +++ src/xend_internal.c 2008-10-06 16:33:42.825335891 +0200 @@ -4268,6 +4268,8 @@ live, live, port, port, resource, 0, /* required, xend ignores it */ + node, -1,/* required, don't know what it is */ + ssl, 0, /* required, should we support it? */ NULL); VIR_FREE (hostname); -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] first argument in virDomainMigrate, is it free'ed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thanks you are too quick :D Richard W.M. Jones schreef: On Mon, Oct 06, 2008 at 06:15:08PM +0200, Stefan de Konink wrote: I saw that freeing the dom after a migration takes place results in: libvir: Domain error : invalid domain pointer in virDomainFree That would be a bug ... I'll try to figure out if it is in my code, or that I can reproduce it with some sample code. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjs3OcACgkQYH1+F2Rqwn023ACghl4+nroZXFgGUexPCH08DJpw uZ4AoItG2BxFogYnBh3kt2amVjis1LFM =OOIv -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Xen and out of memory stuff, blocks libvirtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [2008-10-08 19:14:05 13001] ERROR (XendCheckpoint:157) Save failed on domain klant1_monetdb (17) - resuming. Traceback (most recent call last): File usr/lib64/python2.5/site-packages/xen/xend/XendCheckpoint.py, line 125, in save forkHelper(cmd, fd, saveInputHandler, False) File usr/lib64/python2.5/site-packages/xen/xend/XendCheckpoint.py, line 358, in forkHelper child = xPopen3(cmd, True, -1, [fd, xc.handle()]) File usr/lib64/python2.5/site-packages/xen/util/xpopen.py, line 100, in __init__ self.pid = os.fork() OSError: [Errno 12] Cannot allocate memory [2008-10-08 19:14:05 13001] DEBUG (XendDomainInfo:2456) XendDomainInfo.resumeDomain(17) After this point, I am unable to contact the libvird daemon. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjs7qQACgkQYH1+F2Rqwn0heQCeNJWDo2h3BR1IhcXmt+w9tpjD 304An1SlqWbig7nL8jgeElzJgu/KqgIa =dl3M -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Xen and out of memory stuff, blocks libvirtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Daniel P. Berrange schreef: On Wed, Oct 08, 2008 at 07:32:21PM +0200, Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [2008-10-08 19:14:05 13001] ERROR (XendCheckpoint:157) Save failed on domain klant1_monetdb (17) - resuming. Traceback (most recent call last): File usr/lib64/python2.5/site-packages/xen/xend/XendCheckpoint.py, line 125, in save forkHelper(cmd, fd, saveInputHandler, False) File usr/lib64/python2.5/site-packages/xen/xend/XendCheckpoint.py, line 358, in forkHelper child = xPopen3(cmd, True, -1, [fd, xc.handle()]) File usr/lib64/python2.5/site-packages/xen/util/xpopen.py, line 100, in __init__ self.pid = os.fork() OSError: [Errno 12] Cannot allocate memory [2008-10-08 19:14:05 13001] DEBUG (XendDomainInfo:2456) XendDomainInfo.resumeDomain(17) After this point, I am unable to contact the libvird daemon. Well your host OS has run out of memory, so pretty much everything will be fubar at this point. If it can't even fork() then there's not much libvirt until this is resolved. libvirt tries to handle OOM scenario but there's some places we might have missed, but even so, the best libvirt can do is to drop all further requests as gracefully as possible. Not quite right, the host OS still has 32MB of memory at this point. But I agree strange things, even with later saves. If there is anything that is able to remove that painful xend stuff... I'm happy to give it a shot. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjs9HMACgkQYH1+F2Rqwn2RygCdF37bTe5yxGaMxF+cSRIRqTAX sH4An341jO4GSiWG84if9zEScS09XBgZ =rG7F -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Xen and out of memory stuff, blocks libvirtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Daniel P. Berrange schreef: This is nothing todo with XenD - the error shows fork() failed due to lack of OS memory. Whether running XenD or not, if the kernel runs out of memory you're doomed. You need more RAM allocated to your host. If XenD eats 90% of the available memory (at that time 256MB) I am seriously doomed aswell. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjtChkACgkQYH1+F2Rqwn18SQCgjzFHT7lG5tPUsopnQ8+ejeXh 82sAn3kq5/Mj87EYtxitMB/fn7mnozOG =TzFV -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Xen and out of memory stuff, blocks libvirtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Daniel P. Berrange schreef: On Wed, Oct 08, 2008 at 09:29:29PM +0200, Stefan de Konink wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Daniel P. Berrange schreef: This is nothing todo with XenD - the error shows fork() failed due to lack of OS memory. Whether running XenD or not, if the kernel runs out of memory you're doomed. You need more RAM allocated to your host. If XenD eats 90% of the available memory (at that time 256MB) I am seriously doomed aswell. Whatever the cause, its not a libvirt bug. If you think its wrong that XenD is eating 90% of your ram, then speak to the Xen developers - we can't help fix XenD here. Yes you can by providing a great technology preview for the alternate technique where XenD is not required anymore. But I'll have patience, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjtXy4ACgkQYH1+F2Rqwn0GXgCdFke4xY+DVmb3AwFy4F6upbc1 Z0gAn2S/Vvr+oYN97HZu6pZ/zn7AK5Nk =50Us -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Xen Migration does not work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Stefan de Konink schreef: I'm try to migrate using libvirt: virsh # migrate 0802367323_PIQ002 xen://xen002.local/ libvir: Xen Daemon error : POST operation failed: xend_post: error from xen daemon: (xend.err 'Missing parameter: node') virsh -v 0.4.6 Xen 3.3 def domain_migrate(self, domid, dst, live=False, port=0, node=-1, ssl=None): Start domain migration. @param domid: Domain ID or Name @type domid: int or string. @param dst: Destination IP address @type dst: string @keyword live: Live migration @type live: bool @keyword port: relocation port on destination @type port: int @keyword node: use node number for target @type node: int @keyword ssl: use ssl connection @type ssl: bool @rtype: None @raise XendError: Failed to migrate @raise XendInvalidDomain: Domain is not valid And I don't have a clue what 'node' means in this respect. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjqC4AACgkQYH1+F2Rqwn3XKwCeJSoYXQN2HdfFMvgbdUNb+zxF +WMAnRyHy8rknbfgUsnx/9M7J+3VM5uz =CvM/ -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] first argument in virDomainMigrate, is it free'ed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I saw that freeing the dom after a migration takes place results in: libvir: Domain error : invalid domain pointer in virDomainFree Now I wonder, if this is the case, could a normale migrate function 'just' be: domain = virDomainMigrate(domain, ) Or is this unsafe; for example as a domain migration fails? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjqOYwACgkQYH1+F2Rqwn0NZACffFESznbeElKNVgt65YXPGzXX ausAmwZ7HScE0/RTtDWm2uug/dC1S21K =xpn6 -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Xen Migration does not work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm try to migrate using libvirt: virsh # migrate 0802367323_PIQ002 xen://xen002.local/ libvir: Xen Daemon error : POST operation failed: xend_post: error from xen daemon: (xend.err 'Missing parameter: node') virsh -v 0.4.6 Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjpagoACgkQYH1+F2Rqwn0yogCfd0+rK0mNrLpmmwclAjRpevlg w4EAn2VOWooBbch7awWpRJs/1Sn7G5ZW =6eZd -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Release of libvirt-0.4.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Gerd Hoffmann schreef: Stefan de Konink wrote: - From your position; is there currently anything in the pipeline so Xen users soon can work without XenD (aka the big memoryleak)? I have patches for qemu creating xen domains directly in my queue of stuff to be merged upstream. Right now (patches) qemu handles the basic stuff only though (no save/restore/migration, only pv guests, ...). If things work out well we might have that in the F11 timeframe. Of course this also depends on Dom0 support in the pv_ops based kernel. I am familiar with your work. But this would also require significant changes to libvirt, right? Never the less; I cannot wait to ditch the xen-tools. Keep up the good work. Stefan ps. F11 timeframe - what does that mean? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjgvbsACgkQYH1+F2Rqwn2ZjwCglSyevJMEEEs/rGTMaE0/I+tf +LcAn0msXrWYl07O9POGQeTbwFcPnVZF =m54a -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Release of libvirt-0.4.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Daniel Veillard schreef: On Fri, Sep 26, 2008 at 09:17:43AM -0700, Dale Bewley wrote: I see that 0.4.5 for F9 just made it through bodhi, but there is no F8 build in bodhi. https://admin.fedoraproject.org/updates/F9/FEDORA-2008-7768 Please release a 0.4.6 F8 update for the benefit of us using F8 dom0. I'm stuck on non-HVM hardware for the foreseeable future, so KVM isn't an option for me. And F9 isn't an option for me since there is no dom0 support. Well it wasn't clear that the new release would really fixes things for the Xen users (which is as we all expect the community still using Fedora 8), is there anything in particular you were looking for in this specific release ? It was looking more risky than potentially useful to update there. - From your position; is there currently anything in the pipeline so Xen users soon can work without XenD (aka the big memoryleak)? Several solutions could implemented this, the patches that qemu does xen, or that libvirt talks to the hypervisor directly I'm really hopeing for that kind of change. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjdS5sACgkQYH1+F2Rqwn3sEgCfUle50POAJ+9PeUhyOR7TL+Nj B8AAn1tU4nJzmmEVpk+qKqy25hqeA89Z =5Nqr -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Libvirtd needs to be always running/
On Wed, 3 Sep 2008, Yushu Yao wrote: It seems that libvirtd has to run with root, is this true? To make itself useful it should be root yes. But why does libvirtd need to run for QEMU? If it's for start/stop/pause vm, is Qemu's command line tool not enough? I presume it works by keeping reference to the domain, and is not able to manipulate the domain if it does not own it... but this is a guess :) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] console not working anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have reopenend the bootloader / bug, because with this fix I was unable to start any host again with respect to console allocation. Did anyone see this problem too? Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAki69PsACgkQYH1+F2Rqwn2X4QCgkHxpu0WDDCKgoRn02P6F3hxw ncIAn09ahmzjjp3LHGuzVZ8LQREOnsoL =WVQk -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] bootloader / BUG
On Sun, 24 Aug 2008, Daniel P. Berrange wrote: On Sun, Aug 24, 2008 at 01:33:34AM +0200, Stefan de Konink wrote: With the tip of DanB I am currently using the inactive XML storage quite satisfied with the concept of first undefining than starting. But there is still a bug. The inactive XML adds a bootloader / tag. Now that is (in my perspective) not a bug, but it it is that libvirt expects a config. In my personal believes the tag shouldn't be there if there is no config; or libvirt should not As I mentioned last time, please file a bug providing the XML you fed to 'virDomainDefine', the output of 'xm list --long VMNAME' and the log /var/log/xen/xend.log Ok done. https://bugzilla.redhat.com/show_bug.cgi?id=459912 Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] bootloader / BUG
With the tip of DanB I am currently using the inactive XML storage quite satisfied with the concept of first undefining than starting. But there is still a bug. The inactive XML adds a bootloader / tag. Now that is (in my perspective) not a bug, but it it is that libvirt expects a config. In my personal believes the tag shouldn't be there if there is no config; or libvirt should not libvir: Xen Daemon error : POST operation failed: xend_post: error from xen daemon: (xend.err 'Error creating domain: Had a bootloader specified, but no disks are bootable') error: Failed to create domain from /mnt/netapp/users/klant2/mono/index.xml I just checked with the last git version and the bug still exists... I hope someone can look into this asap. It is a blocker for development. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] On shutdown Destroy/Delete
Hi, I would really like to know how I can make a defined domain *gone* after shutdown :) (instead of it still be defined, after shutdown) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Reusing dumpxml output
On Thu, 14 Aug 2008, ajishrao wrote: You need to take care of only two parameters ID and VNC port, other things will remain. If you want to put different path for disk you can do that as well. API is already available to define by you own xml. Even if you don't modify the id/vnc it doesn't matter, everything is taken care by libvirt. Technically the VIF also changes, and what I see if I completely reuse the config, it automatically gets a bootloader / (I think it changes to hvm) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Reusing dumpxml output
On Thu, 14 Aug 2008, Daniel P. Berrange wrote: On Thu, Aug 14, 2008 at 01:04:56AM +0200, Stefan de Konink wrote: I would like to reuse configurations that have been edited using the libvirt api. For example by attaching interfaces. Now the output that dumpxml generates, is very 'specific' to an active configuration. I am not able to use a stored configuration from an active domain to redefine it after it has been undefined. Is there a trick to do so? Or should one really strip all 'live' attributes first? The XML is supposed to be idempotent - the XML you get from 'dumpxml' should be able to be fed back into 'create' resulting in exactly the same VM config. Previously there were a few places where you had to tweak the XML, eg to remove the auto-allocated VNC port, or remove the VIF target device name. In current CVS those issues are all fixed, so you should not have to change anything in the XML. So any further problems in this area are definitely bugs. There is also the option to request the 'inactive' XML dump for a running domain which removes any auto-allocated params. This is just a convenience though, and not required for re-creating the VM later. Do you see the bootloader / bug? Or am I using a buggy git version? I'll try the inactive parameter, that should be better in general. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: Bug with bootloader / (Re: [libvirt] Reusing dumpxml output)
On Thu, 14 Aug 2008, Stefan de Konink wrote: On Thu, 14 Aug 2008, Daniel P. Berrange wrote: Then we can see about fixing it adding another test case to ensure it doesn't break again I'm going to upgrade to the latest git to be sure, I'll report back soon. New version fixes the issue. I still have another issue with respect to a segmentation fault on exit (libvirtd), but i'm not able to reproduce it consistently. (I think it is with respect to an umount) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] breaking out of virsh console?
On Thu, 14 Aug 2008, Daniel P. Berrange wrote: On Thu, Aug 14, 2008 at 02:26:57PM -0400, Andrew Cathrow wrote: On Thu, 2008-08-14 at 11:23 -0700, Schroeder, Paul wrote: Hello all... In my VM's inittab, I set agetty to run on ttyS0 so I could do virsh console myvm and log in from the host machine's command line. It works perfectly. Trouble is, I don't know how to break out of it to get back to the command line on my host. I've only been able to do so by killing the virsh process. There's gotta be a better way.. Right? ctrl + ] Patches to add documentation to this effect in the virsh.pod man page and / or website HTML pages are welcomed :-) With respect to this. Does anyone have a pam configuration to connect to vm ([EMAIL PROTECTED])? My current plan is to extend my mDNS based libvirt implementation with one login server that is able to connect to any of my other nodes in the network. But if anyone has something I can base a PAM configuration on I'm happy to reuse it :) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VMWare support, any news?
On Thu, 14 Aug 2008, Yushu Yao wrote: Thanks Daniel, Could you point me to the simplest example of one other back-end? (I looked into test one but don't know if it has been different after refactoring). So, consider VMPlayer as an example, I need simply do a system call vmplayer --xxx yyy.vmx in the driver implementation? Am I understanding it correctly? Ideally you would implement the API used for ESX ;) but vmware player could be a start :) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Reusing dumpxml output
I would like to reuse configurations that have been edited using the libvirt api. For example by attaching interfaces. Now the output that dumpxml generates, is very 'specific' to an active configuration. I am not able to use a stored configuration from an active domain to redefine it after it has been undefined. Is there a trick to do so? Or should one really strip all 'live' attributes first? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] virDomainInterfaceStats why is there a size?
Another simple question, what is the reasoning about the size field in this call. I would really be a happy boy if anyone said: if you put in path == NULL, it will fill your stats structure up to size interfaces. ...but since this is not the case (yet) what is the reason behind it? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] virStoragePoolRefresh (costs)
Could anyone elaborate on the cost of running virStoragePoolRefresh on the different backends. I recall one of the Daniels here suggested it was expensive for some backends could anyone elaborate on it? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] /var/run/libvirt
On Sat, 9 Aug 2008, Guido Günther wrote: On Sat, Aug 09, 2008 at 09:56:45AM +0100, Richard W.M. Jones wrote: [..snip..] Dan/Dan, any reason we can't 'mkdir' this when libvirtd starts up? Shoulnd't this better be handled in the distros init script? If that is your argument, then please remove the chmod code too :) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] /var/run/libvirt
It is a trivial error, but i wonder if: Failed to change group ownership of /var/run/libvirt Failed to bind socket to '/var/run/libvirt/libvirt-sock': No such file or directory This could be corrected to: /var/run/libvirt doesn't exist or an mkdir is done on the directory... Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] /var/run/libvirt
On Fri, 8 Aug 2008, Daniel Veillard wrote:
On Fri, Aug 08, 2008 at 11:49:46AM +0200, Stefan de Konink wrote:
It is a trivial error, but i wonder if:
Failed to change group ownership of /var/run/libvirt
Failed to bind socket to '/var/run/libvirt/libvirt-sock': No such file or
directory
This could be corrected to:
/var/run/libvirt doesn't exist
or an mkdir is done on the directory...
I see
install -d -m 0755 $RPM_BUILD_ROOT%{_localstatedir}/run/libvirt/
in libvirt spec file and
mkdir -p $(DESTDIR)$(localstatedir)/run/libvirt
in qemud/Makefile.am as part of install-data-local rule. So it seems
it really should be created appropriately as part of 'make install'
My /var/run is empty upon boot. (ramfs) One may wonder why libvirt needs a
dedicated directory at all for two sockets...
a better reporting of the error would be fine, but something else went wrong
first.
See the trivial part.
Stefan
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] /var/run/libvirt
On Fri, 8 Aug 2008, Daniel P. Berrange wrote:
On Fri, Aug 08, 2008 at 12:08:05PM +0200, Stefan de Konink wrote:
On Fri, 8 Aug 2008, Daniel Veillard wrote:
install -d -m 0755 $RPM_BUILD_ROOT%{_localstatedir}/run/libvirt/
in libvirt spec file and
mkdir -p $(DESTDIR)$(localstatedir)/run/libvirt
in qemud/Makefile.am as part of install-data-local rule. So it seems
it really should be created appropriately as part of 'make install'
My /var/run is empty upon boot. (ramfs) One may wonder why libvirt needs a
dedicated directory at all for two sockets...
That just happens to be your particular deployment scenario. Other
hypervisor drivers put stuff in there too, hence we have a directory.
Anyway, it is a trivial fix... if I need to write a patch myself, so be
it.
Stefan
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ISCSI Live Migration with LUN backed VMs
On Thu, 7 Aug 2008, Tim Hughes wrote: I am using iscsi backed VMs which use a separate LUN for each VM. This is all good until I try to live migrate because the LUN is not logged into on the new machine. Does anyone have a way of handling logging into and out of iscsi luns during the migration ? There are patches floating on this list to make that possible. My own Xen based solution involves a block script for Xen, but the current libvirt solution should work too. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ISCSI Live Migration with LUN backed VMs
On Thu, 7 Aug 2008, Daniel P. Berrange wrote: On Thu, Aug 07, 2008 at 12:19:01PM +0100, Tim Hughes wrote: I am using iscsi backed VMs which use a separate LUN for each VM. This is all good until I try to live migrate because the LUN is not logged into on the new machine. Does anyone have a way of handling logging into and out of iscsi luns during the migration ? In general its the responsibility of the application/admin triggering the migration to ensure that the destination host has the same storage and network configuration. There's nothing special about iSCSI in this regard really - FibreChannel/NFS/Cluster-LVM/etc all have the same core requirements. If you have a bunch of hosts you wish to migrate between, then you need to configure them all to have matching resources The fact that libvirt still doesn't automatically uses the result of send targets won't make it more easy for its users :) ...but we also had this discussion before. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] storage pool discovery
Daniel P. Berrange schreef: On Mon, Aug 04, 2008 at 11:19:25AM +0200, Stefan de Konink wrote: Daniel P. Berrange schreef: On Mon, Aug 04, 2008 at 11:02:33AM +0200, Stefan de Konink wrote: On Mon, 4 Aug 2008, Daniel P. Berrange wrote: - - For iSCSI and related stuff everything was relatively easy, because this would just mean to write the right /dev/blabla to the xenstore. What is your idea to get different drivers working via: virt://pool/volume (so basically blktap vs file vs disk) My idea was to have a script in /etc/xen/scripts/ Me too, but in order to 'fetch' the actual configuration it is required to contact libvirt. And query about the pool/volume location. In this way it would be actually a 'redirection' to blktap or adding a devicepath. So this script is now written in plain C, but I want to know how you imagine the driver selection based on connection uri. You can simply use xen:/// as the URI. There is no need for configurable URIs since thisis a xen specific script. You don't get the issue. In order to run a specific script for example a block device, it should have an unique prefix. That will make the executable that is called so virt:// will call /etc/xen/scripts/block-virt as script. As you might notice here, the common file://, tap:aio:// or psy:// is not present, so if a pool is file based or device based it should some how inform this 'script' how to redirect the parameters to the appropriate script. This is what the driver tag in the XML can be used for. It can include a driver name (file, phys, tap) and subtype (raw, aio, qcow, etc). You just need to decide how to encode this info when passing it to Xend. Yes... and this was exactly my question ;) So if we have a pool and want to send it to xen it would look something like: virt://driver/pool/volume, now the 'tiny' problem is that I don't want to reimplement every possible driver. So I'll do some research in order to pass a connection url exported by libvirt to the 'default' scripts, while maintaining the virt:// in xen. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] storage pool discovery
Daniel P. Berrange schreef: On Mon, Aug 04, 2008 at 11:02:33AM +0200, Stefan de Konink wrote: On Mon, 4 Aug 2008, Daniel P. Berrange wrote: - - For iSCSI and related stuff everything was relatively easy, because this would just mean to write the right /dev/blabla to the xenstore. What is your idea to get different drivers working via: virt://pool/volume (so basically blktap vs file vs disk) My idea was to have a script in /etc/xen/scripts/ Me too, but in order to 'fetch' the actual configuration it is required to contact libvirt. And query about the pool/volume location. In this way it would be actually a 'redirection' to blktap or adding a devicepath. So this script is now written in plain C, but I want to know how you imagine the driver selection based on connection uri. You can simply use xen:/// as the URI. There is no need for configurable URIs since thisis a xen specific script. You don't get the issue. In order to run a specific script for example a block device, it should have an unique prefix. That will make the executable that is called so virt:// will call /etc/xen/scripts/block-virt as script. As you might notice here, the common file://, tap:aio:// or psy:// is not present, so if a pool is file based or device based it should some how inform this 'script' how to redirect the parameters to the appropriate script. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] storage pool discovery
On Mon, 4 Aug 2008, Daniel P. Berrange wrote: - - For iSCSI and related stuff everything was relatively easy, because this would just mean to write the right /dev/blabla to the xenstore. What is your idea to get different drivers working via: virt://pool/volume (so basically blktap vs file vs disk) My idea was to have a script in /etc/xen/scripts/ Me too, but in order to 'fetch' the actual configuration it is required to contact libvirt. And query about the pool/volume location. In this way it would be actually a 'redirection' to blktap or adding a devicepath. So this script is now written in plain C, but I want to know how you imagine the driver selection based on connection uri. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] When are volumes 'detected' / refreshed
At what time are volumes currently detected on NetFS? I see there is some sort of storage now going on, since deleting files from NFS doesn't delete them from vol-list directly. (If this is fixed in a recent version... I'm sorry to bother) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] storage pool discovery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Daniel, Stefan de Konink schreef: As you know I wrote such thing for iSCSI/Solaris, iSCSI/Netapp so... if you want such script I can fabricate something, maybe it would be interesting to not create a script, but instead a binary that links to libvirt and is able to lookup the connection url and creates the xenstore stuff. I have some code now that basically parses the XENBUS_PATH/param and looks it up in libvirt. Now I have some questions: - - Is it possible to reuse the hypervisor connection from within libvirt? I would like to make this working: xenUnifiedPrivatePtr priv = (xenUnifiedPrivatePtr) conn-privateData; - - For iSCSI and related stuff everything was relatively easy, because this would just mean to write the right /dev/blabla to the xenstore. What is your idea to get different drivers working via: virt://pool/volume (so basically blktap vs file vs disk) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkiVFgIACgkQYH1+F2Rqwn2RcgCfQCXeZA6OTqGsoWYMH6yW20dy dL4AnAtilh4ezQLtyulGeuoAt4XXrCJ4 =6S5u -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] storage pool discovery
Daniel, When this gets in; would it get more easy to lookup a file-storagepool. In order to make the alternative configuration I proposed for domains working? (Basically providing pool/volume instead of filename) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] storage pool discovery
On Fri, 1 Aug 2008, Daniel P. Berrange wrote: On Fri, Aug 01, 2008 at 11:46:14AM +0200, Stefan de Konink wrote: Daniel, When this gets in; would it get more easy to lookup a file-storagepool. In order to make the alternative configuration I proposed for domains working? (Basically providing pool/volume instead of filename) I don't think it'll make any significant difference - we can do the alternate XML syntax you proposed already. I think it might be nice to use a different approach to the Xen impl of it though. Previously have had done the poool/volume - filename conversion in libvirt before passing the data to XenD. This means that when you don't the XML you get the filename instead of pool/volume details, and doesn't deal with potentially different filenames upon migration. So I'd like to see if its possible to write a custom script for xen to go in /etc/xen/scripts. So we can pass in a pool/volume to Xend and have it auto-lookup the file at time of hotplug. As you know I wrote such thing for iSCSI/Solaris, iSCSI/Netapp so... if you want such script I can fabricate something, maybe it would be interesting to not create a script, but instead a binary that links to libvirt and is able to lookup the connection url and creates the xenstore stuff. But as you look at it now, this gets very close to what XenD is doing, so if we implement it in this way, why not do everything that is required ;) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Now ESXi is 'free'
Now ESXi is 'free as in beer' would it be appropriate to hack a libvirtd in it? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [FeatureRequest/RFC] non-volitile domain defines
Daniel P. Berrange schreef: On Wed, Jul 23, 2008 at 03:16:57AM +0200, Stefan de Konink wrote: I think I have already sent an email about this to the list, but no reply on this specific point. Libvirt is currently capable of storing storage, networks, the only thing that is really missing is the direct storage of domains. I wonder if a patch would be accepted that stores defined domains (live) to disk upon change. Some sort of dumpxml per define/attach/etc. when a domain is undefined the file is removed. The storage of persistent configurations is implementation defined. With some drivers libvirt takes care of it directly, with others it is delegated to the underlying hypervisor specific tools. We're not going to replicate that in libvirt because it'll cause interoperability problems with tools which aren't libvirt based DV: sorry, wrong webclient. DP: Would a patch be accepted that makes this configurable for *all* implementations? So that by after configuration a file is saved, and is queried after the platform specific implementation doesn't list the domain as defined? List Defined domains: - Query current implementation - If defined merge all non available domains. In principle what I want to see is that if a domain is not defined in the specific hypervisor, the domain file can be queried. I know I can implement this behavior in my own code, but I really thing this would be a cool thing for more people. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [FeatureRequest/RFC] non-volitile domain defines
Daniel P. Berrange schreef: On Wed, Jul 23, 2008 at 11:54:11AM +0200, Stefan de Konink wrote: DP: Would a patch be accepted that makes this configurable for *all* implementations? So that by after configuration a file is saved, and is queried after the platform specific implementation doesn't list the domain as defined? List Defined domains: - Query current implementation - If defined merge all non available domains. In principle what I want to see is that if a domain is not defined in the specific hypervisor, the domain file can be queried. I know I can implement this behavior in my own code, but I really thing this would be a cool thing for more people. This doesn't make any sense. We have APIs for listing defining inactive domains. The individual drivers implement these APIs according to the required API contract, and the underlying impl is not something which any application using libvirt need know or care about. If your application is relying on the inactive domains being stored in files it is broken. Or you could say that libvirt is broken because it isn't able to distribute the inactive domains across the network in a consistent way. But I think we already had that discussion. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [FeatureRequest/RFC] non-volitile domain defines
Daniel P. Berrange schreef: On Wed, Jul 23, 2008 at 12:43:25PM +0200, Stefan de Konink wrote: Daniel P. Berrange schreef: On Wed, Jul 23, 2008 at 11:54:11AM +0200, Stefan de Konink wrote: DP: Would a patch be accepted that makes this configurable for *all* implementations? So that by after configuration a file is saved, and is queried after the platform specific implementation doesn't list the domain as defined? List Defined domains: - Query current implementation - If defined merge all non available domains. In principle what I want to see is that if a domain is not defined in the specific hypervisor, the domain file can be queried. I know I can implement this behavior in my own code, but I really thing this would be a cool thing for more people. This doesn't make any sense. We have APIs for listing defining inactive domains. The individual drivers implement these APIs according to the required API contract, and the underlying impl is not something which any application using libvirt need know or care about. If your application is relying on the inactive domains being stored in files it is broken. Or you could say that libvirt is broken because it isn't able to distribute the inactive domains across the network in a consistent way. No, because that is not libvirt's job. The goal of libvirt is to provide an API for managing virtualization capabilities on a host. Data center or network management is an application level problem, out of scope for libvirt. That calls for a libvirt-fork that does implement what is needed to consistently providing a replicated pool of domains; call it libvirt-datacenter-edition. I think it is the biggest non sense for implementing shortcommings/management in kvm/qemu, but don't provide these to the other hypervisors 'just because they implement it theirselves locally'. It is non-trivial to provide a 'xenstored' for the complete network, while it is relatively easy to put an NFS dir on the libvirt xml configs. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [FeatureRequest/RFC] non-volitile domain defines
I think I have already sent an email about this to the list, but no reply on this specific point. Libvirt is currently capable of storing storage, networks, the only thing that is really missing is the direct storage of domains. I wonder if a patch would be accepted that stores defined domains (live) to disk upon change. Some sort of dumpxml per define/attach/etc. when a domain is undefined the file is removed. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] leak? xenUnifiedOpen
==5486== 184 bytes in 1 blocks are definitely lost in loss record 5 of 18 ==5486==at 0x4C20111: calloc (vg_replace_malloc.c:397) ==5486==by 0x4E3ADFD: __virAlloc (memory.c:100) ==5486==by 0x4E4AF21: xenUnifiedOpen (xen_unified.c:264) ==5486==by 0x4E3A005: do_open (libvirt.c:777) ==5486==by 0x4009D7: main (in /home/skinkie/development/htdocs/cherokee/experiment) Maybe valgrind is over active, because I see the free code at the close connection, and my own code is closing it... Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Inconsistency with documentation virDomainGetMaxMemory(NULL)
I was making a some test code to checkout some code before I start on my brand new Invite/Tender cluster distribution engine(tm ;) From docs: Retrieve the maximum amount of physical memory allocated to a domain. If domain is NULL, then this get the amount of memory reserved to Domain0 i.e. the domain where the application runs. [EMAIL PROTECTED] ~/development/htdocs/cherokee $ ./experiment libvir: Domain error : invalid domain pointer in virDomainGetMaxMemory 0 262144 Code: printf(%ld\n, virDomainGetMaxMemory(NULL)); virDomainPtr domu = virDomainLookupByName(conn, klant1_gentoo); printf(%ld\n, virDomainGetMaxMemory(domu)); virDomainFree(domu); Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Inconsistency with documentation virDomainGetMaxMemory(NULL)
Stefan de Konink schreef: From docs: Retrieve the maximum amount of physical memory allocated to a domain. If domain is NULL, then this get the amount of memory reserved to Domain0 i.e. the domain where the application runs. Doing it the 'proper' way gives an even more interesting answer: virDomainPtr domu = virDomainLookupByID(conn, 0); printf(%ld\n, virDomainGetMaxMemory(domu)); 17179869180 Now... MemTotal: 7990272 kB MemFree: 7527312 kB Buffers: 44400 kB Cached: 50440 kB SwapCached: 0 kB Active: 133236 kB Inactive:63764 kB SwapTotal: 0 kB SwapFree:0 kB Dirty: 476 kB Writeback: 0 kB AnonPages: 102216 kB Mapped: 10848 kB Slab:20428 kB SReclaimable: 7800 kB SUnreclaim: 12628 kB PageTables: 2648 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit: 3995136 kB Committed_AS: 568940 kB VmallocTotal: 34359738367 kB VmallocUsed: 412 kB VmallocChunk: 34359737775 kB That doesn't make sense. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Inconsistency with documentation virDomainGetMaxMemory(NULL)
Stefan de Konink schreef: Stefan de Konink schreef: From docs: Retrieve the maximum amount of physical memory allocated to a domain. If domain is NULL, then this get the amount of memory reserved to Domain0 i.e. the domain where the application runs. Doing it the 'proper' way gives an even more interesting answer: Checking the free memory also results in strange measures: printf(%llu\n, virNodeGetFreeMemory(conn)); 28672 That doesn't make sense. I'm running the lastest git version of libvirt... Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Inconsistency with documentation virDomainGetMaxMemory(NULL)
Stefan de Konink schreef: That doesn't make sense. I'm running the lastest git version of libvirt... And it seems libvirt cannot handler ballooning. With a hard dom0_mem=limit, I get good values back. Never the less, xm info also returned 0 with the ballooning on. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] virStorageVolCreateXML vs virStorageVolCloneXML
Hi, There is currently no implementation in the api to clone snapshots or images. I wonder if we could add an XML node to specify a backed device. Or add a new function that allows to clone. Like the create is not supported by all pools, cloning should also be based on best effort, falling back to cp for non sparse images. (Probably a good configuration option) Now the new XML parser is in place I have still the desire to create this type of configuration: disk type='pool' source pool='netapp' volume='lun-3' / target dev='xvda'/ /disk And it might be a useful source tag for cloning too. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Libvirtd default.xml (in qemu/networks/autostart) breaks XEN
The desire to automatically install the autostarted network configuration of libvirt broke my (and some other users on xen-users) setup. I suggest to *remove* this network configuration as default and *not* put it into xenstore as a stateful config. *It does not work by default* Worse is that it is almost impossible to debug if you don't know where to find it. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virStorageVolCreateXML vs virStorageVolCloneXML
Daniel P. Berrange schreef: On Fri, Jul 18, 2008 at 12:27:49PM +0200, Stefan de Konink wrote: Hi, There is currently no implementation in the api to clone snapshots or images. I wonder if we could add an XML node to specify a backed device. Or add a new function that allows to clone. I think this wants to be done with a new API, taking a source volume, and destination pool as the arguemnts. Something along the lines of virStorageVolClone(virStorageVolPtr src, virStoragePoolPtr dst, unsigned int flags); It looks pretty indeed. I'll try if I can implement this. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] some unsorted questions
Daniel P. Berrange schreef: In the case of the Xen drivers, this requires O(n) calls to XenD which are rather expensive. XenD does actually have ability to return data about all domains in a single request. So if we had an API for fetching all domains at once it'd only require O(1) expensive XenD calls. I'd imagine something like this int virConnectListAllDomains(virConnectPtr conn, virDomainPtr **domains, int stateflags); The 'stateflags' parameter would be a bit-field where each bit corresponded to one of the virDomainState enumeration values. The 'domains' list would be allocated by libvirt, and filled in with all the domain objects, and the total number of domains as the return value. Yes; initially I was looking for something like this. I think this is a great idea. Now I wonder, if it could be faster (with the lookup mechanism) to check if the domain exists, before connecting to it. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Updating xml (cmdline)
Hi, Is it possible to 'update' a defined domain before it is started. I have run into a chicken and egg problem related to the cmdline and the first ethernet interface, I cannot create the interface before I have a domain and visa versa. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] some unsorted questions
Hi, Currently I'm working on my webserver thingie. And I notice some annoying error messages. Generally I use a predefined host to do the basic setup of defining a domain. So a client can shoot its XML directly into a post request, or we set it up by parsing some parameters from the URI. Now personally I think it is smart to check if a domain is already defined, or in use. If this is not the case libvirtd and the client get this message: libvir: Xen Daemon error : GET operation failed: That doesn't seem to fit the scenario at all :) Why does lookupbyname behave so bad? Secondly; I am a bit distracted by the domids concept. These ids are not available before a domain is launched. I think it would be interesting to allow signed values. In this way the 'defined' not active domains would get a negative value and a running domain a positive value. (Dom0 gets 0) This would have far less implications than using an uuid through the codebase consistently (not speaking the about the extra overhead). If this gets implemented I would suggest a call that fetches all domains from a running system and not only the defined or only the active ones. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] attach device on a defined (non-active) vm
It seems that the attach device function really 'attaches' a (live) device to a non-active domain. Is this by design? Otherwise I would not have a clue how to interpreted this message: libvir: Xen Daemon error : POST operation failed: (xend.err 'Device /dev/xvdp (51952, tap) is already connected.') (when I try to start the domain) So what I did; I have created an empty domain without any devices. Loaded that and added a disk. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Web Interface - LibVirt Communication?
Henri Cook schreef: I want to write a web tool that lets me administer my cluster from one location (including operations that things like virt-manager don't provide) - what's the proper way of achieving this? Can i communicate over TCP with libvirt on each server (is this documented?) or should I be trying to get my web app to auth and run virsh commands over SSH? I have implemented this using Avahi and created a webserver handler for Cherokee. http://repo.or.cz/w/handlervirt.git My demo is just taken offline for hardware migration purposes, but if you want to team up, let me know :) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Web Interface - LibVirt Communication?
Michael March schreef: .. in this setup you MUST have the ssh public key of the user the web server runs as in the 'root' account of each server it manages.. again, this might not be 100% kosher.. but it works. The main problem I encounter is the hostname voodoo...but that check can be disabled. I probably make an automatic hostname based on mac address, and send that via SSH to the main box. A shared certificate is probably an option too, if the hostname is ignored. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Web Interface - LibVirt Communication?
Michael March schreef: Michael March schreef: .. in this setup you MUST have the ssh public key of the user the web server runs as in the 'root' account of each server it manages.. again, this might not be 100% kosher.. but it works. The main problem I encounter is the hostname voodoo...but that check can be disabled. I probably make an automatic hostname based on mac address, and send that via SSH to the main box. A shared certificate is probably an option too, if the hostname is ignored. Hmm.. I'm not sure what you exactly mean by hostname voodoo Do you mean the checks the ssh client does the first time it connects to an unknown server? No I mean that the certificate is not valid if the hostname doesn't match. (It is possible to disable that in the connection string though) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Web Interface - LibVirt Communication?
Michael March schreef: Stefan de Konink wrote: Michael March schreef: Michael March schreef: .. in this setup you MUST have the ssh public key of the user the web server runs as in the 'root' account of each server it manages.. again, this might not be 100% kosher.. but it works. The main problem I encounter is the hostname voodoo...but that check can be disabled. I probably make an automatic hostname based on mac address, and send that via SSH to the main box. A shared certificate is probably an option too, if the hostname is ignored. Hmm.. I'm not sure what you exactly mean by hostname voodoo Do you mean the checks the ssh client does the first time it connects to an unknown server? No I mean that the certificate is not valid if the hostname doesn't match. (It is possible to disable that in the connection string though) All I did was make sure I ssh'd as a 'real' user first.. using whatever hostname I was using for the ssh endpoint.. if that went well (making sure I didn't have to enter a password or ssh key pass-phrase) I was pretty certain the libvirt connection would work. However.. other messages on this thread are recommending against the ssh method.. I'm going to try the recommended Digest-MD5 method now too I'm using the tls connection not ssh. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 10/14: Convert XenD XML parser to generic API
Daniel P. Berrange schreef: This replaces the code which converts from the XML into SEXPR with code which converts from the virDomainDefPtr object to a SEXPR. We then simply use virDomainDefParseString() to generate the initial virDomainDefPtr. This makes the SEXPR generating code much easier to follow. Could you elaborate on why you are using the SEXPR instead of the XenAPI XML code? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: 10/14: Convert XenD XML parser to generic API
Daniel P. Berrange schreef: On Tue, Jul 08, 2008 at 06:48:45PM +0200, Stefan de Konink wrote: Daniel P. Berrange schreef: This replaces the code which converts from the XML into SEXPR with code which converts from the virDomainDefPtr object to a SEXPR. We then simply use virDomainDefParseString() to generate the initial virDomainDefPtr. This makes the SEXPR generating code much easier to follow. Could you elaborate on why you are using the SEXPR instead of the XenAPI XML code? SEXPR works for all XenD. XenAPI only works for XenD = 3.1.0 Ok that makes sence :) At least from a less work, more fun perspective. We're open to having an XenAPI impl too, but so far no one's provided an impl and its not really a high priority since existing impl works fine Ok Ok :) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] HTTP-API for libvirt
Daniel P. Berrange schreef:
It is what I proposed to be in libvirtd (native support for clouds), but
then implemented as a client application for libvirtd, that is a service
provider for avahi. And a webserver plugin for Cherokee that is a client
for avahi. Something as namespace collision prevention is something that
is 'on going'.
How tied is the webserver plugin to Cherokee - I think you'd get more
interest if there was the option to plugin to apache, since Cherokee
isn't very widely used / known by comparison. Having never written
plugins for either I don't know if this is possible, but having a
generic plugin for the application logic and then bridges to apache,
cherokee other web servers would be nice.
I wrote it for Cherokee because I like Cherokee and I think Cherokee
kicks Apache + Lighttpd ass ;) No seriously I wrote it as real C code
plugin to get integration without dependencies on interpreter languages,
but I guess anyone would be able to do the same thing in Python, once a
standard has been set.
I'd be interested in seeing the source to understand better what it
is doing. I'd certainly be fine with adding it to our applications
page on the website wiki.
http://repo.or.cz/w/handlervirt.git
I've had a quick look, but not got it up running due to not having
cherokee in Fedora. My first thought would be that the URL spec needs
to be more fine-grained / well-defined.
There must be an RPM floating around, was on the mailinglist lately, but
since it is external plugin development, it is still a bit 'LFS' like to
get it running.
Virtual machine names are only guarenteed to be unique to a single host,
so with your avahi broadcasts aggregating info from multiple hosts you
will inevitably get namespace clashes based on name alone.
True, but my intention is to start the host from the webservice too.
Only if it is not present on the network. Exactly this can be prevented,
*if* libvirtd would look on the network (aka integrate all this in
libvirtd).
I'd provide several parallel URL spaces based on the different naming
/vm/{UUID}/
/host/{HOSTNAME}/vm/{NAME}
/host/{HOSTNAME}/vm/{ID}
UUID is guarenteed to be unique globally, while the other two are only
per-host unique. I included the /vm/ prefix under the /host/ so you
can also expose other bits of per-host information such as networking,
capabilities and device info, eg for virtual networks:
/vnet/{UUID}/
/host/{HOSTNAME}/vnet/{NAME}
I'd also thing of structuring it so that the default install just gives
info on a single host, and then have an add-on plugin to enable the
multi-host aggregration. You could have a /local/ shortcut URI to refer
to the /host/{HOSTNAME} of the local machine. This gives admins the
flexibility to run a mini web service on each node, or have a central
service on a 3rd part node.
I need the user as separate thing too, because I want to have different
users (thus different authentication). I don't really get why you want
to 'webservice' libvirt per host... but the current implementation will
work transparently. You can start it on any machine, and it would
probably be possible to only take 'local' avahi domains.
Stefan
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Packaged Java bindings for libvirt
Daniel Veillard schreef: I will submit this for Fedora inclusion too, feedback and patches very welcome. I wonder, now I have created a HTTP version of the (partial) API, would it be possible to get it adopted here? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] HTTP-API for libvirt
New thread. Honnestly I'm still lost trying to understand what you wanted to do. I have implemented a webserver plugin that allows (by mDNS) to access all 'VMs' on the network. http://xen.bot.nu/virt/ - demo I didn't understand the point, I just noted you wanted to put things in libvirtd, something about event API while to me i don't see the even side of the proposal. Using mDNS, mDNS events can be used on the network to subscribe to certain VM changes. Reboot/Shutdown/etc. Now suggesting to convey this as part of Java *bindings* sounds even more confusing, how does that relate at all ? You proposed (new) bindings for Java. I have written new bindings using the HTTP protocol. I wonder what should be done to get it adapted into libvirt, or standardize the format (like any other API). Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] HTTP-API for libvirt
Daniel P. Berrange schreef: If I'm understanding what you're doing, it is sort of a REST style web services API. Why is everyone using this REST buzzword lately? :D It is also adding in certain higher level API semantics by using mDNS to aggregate info from multiple hosts ? It is what I proposed to be in libvirtd (native support for clouds), but then implemented as a client application for libvirtd, that is a service provider for avahi. And a webserver plugin for Cherokee that is a client for avahi. Something as namespace collision prevention is something that is 'on going'. I propose to integrate the libvirtd-client/avahi-service provider (domumdns in the sourcetree) into libvirtd. As such its kind of straddling the boundary between being a service vs an application. It is. But you could also see it as a 'protocol' that is implemented by an application. What I want to get formalized how such protocol *should* look like. I'd be interested in seeing the source to understand better what it is doing. I'd certainly be fine with adding it to our applications page on the website wiki. http://repo.or.cz/w/handlervirt.git I'm wary of proprosing an 'offficial' web application since there are many people building web applications ontop of libvirt[1] I don't want to take sides saying one is better than the other. I don't want you to pick sides, but I want to get the 'protocol' formalised or at least molded into something that has been done for the Python API. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] FYI: Major driver re-factoring imminent...
On Mon, 16 Jun 2008, Daniel P. Berrange wrote: This is a quick FYI to say that I've started working on the plan to provide a single unified XML parser and generator for all hypervisor drivers, in addition to the virtual network drivers. Very good! This will reduce the complexity of adding features significantly :) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt+avahi domain publication daemon / webhandler
Hi, As notified before I am working on a daemon that publishes domains and looking in the close future state changes. I have implemented this daemon so my webserver handler is able to figure out where to connect to in the network upon a request. In my opinion this functionality should be in libvirtd, but people highly differ on this opinion. Currently it is an external program that polls with an interval of 10 seconds. This webserver has access to all certificates to connect to the remote boxes. And authentication can be based on HTTP_auth, thus also implement specific vm/functions to be accessed. Basically: GET /libvirt/user/vm/virDomainGetID Will look up user_vm using avahi, if not found, result in a 404. If the domain is found the result is returned in the body. POST /libvirt/user/vm/virDomainAttachDevice disk type='file' driver name=tap type=aio source file='/var/lib/xen/images/fv0'/ target dev='hda' bus='ide'/ /disk Will look up user_vm using avahi, if not found, result in a 404. If the domain is found the command is executed using the post body. And the result value is put in the return body. If anyone is interested in working on this or has comments shoot :) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5]: Rework iSCSI lun handling
Chris Lalancette schreef: 4) Further lessen our dependence on direct calls to iscsiadm, in case they change the output in the future. How are you looking against this previous proposed setup where we will give an updated Makefile to the open-iscsi folks (to build libopen-iscsi.so) and implement an specific open-iscsi iscsi driver that uses the exact same functions as open-iscsi does itself? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5]: Rework iSCSI lun handling
Chris Lalancette schreef: Stefan de Konink wrote: Chris Lalancette schreef: 4) Further lessen our dependence on direct calls to iscsiadm, in case they change the output in the future. How are you looking against this previous proposed setup where we will give an updated Makefile to the open-iscsi folks (to build libopen-iscsi.so) and implement an specific open-iscsi iscsi driver that uses the exact same functions as open-iscsi does itself? Yeah, it's not a bad plan at all. Someone just needs to work with upstream open-iscsi tools to split their stuff out into a library. I'm totally for this type of implementation; not only will we not have to fork and exec for some of this stuff, we should be able to get better error messages as well. The I have looked at there Makefile before, and build this. They already mark there 'libraries'. So it would be only one update... That being said, until this sort of change makes it upstream, we have to work with what we've got at the moment. True, but also: it will only work with new versions of open-iscsi, so the sooner we get the 'fix/enhancement' the more chance our new implementation will have. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5]: Rework iSCSI lun handling
Daniel P. Berrange schreef: On Mon, Jun 16, 2008 at 04:10:42PM +0200, Stefan de Konink wrote: Chris Lalancette schreef: Stefan de Konink wrote: Chris Lalancette schreef: 4) Further lessen our dependence on direct calls to iscsiadm, in case they change the output in the future. How are you looking against this previous proposed setup where we will give an updated Makefile to the open-iscsi folks (to build libopen-iscsi.so) and implement an specific open-iscsi iscsi driver that uses the exact same functions as open-iscsi does itself? Yeah, it's not a bad plan at all. Someone just needs to work with upstream open-iscsi tools to split their stuff out into a library. I'm totally for this type of implementation; not only will we not have to fork and exec for some of this stuff, we should be able to get better error messages as well. The I have looked at there Makefile before, and build this. They already mark there 'libraries'. So it would be only one update... As I've said before, while this is useful in the long term, this doesn't make the existing code go away. We need to be able to spport iSCSI on RHEL-5 vintage which has no such library. Does RHEL-5 vintage have libvirt? But I acknowledge the issue. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC 5/5]: Rewrite findLuns function
+ n = scandir(sysfs_path, namelist, notdotdir, versionsort);
+ if (n = 0) {
+ /* we didn't find any reasonable entries; return failure */
+ virStorageReportError(conn, VIR_ERR_INTERNAL_ERROR,
+ _(Failed to find any LUNs
for session %s: %s),
+ session,
strerror(errno));
+
+ return -1;
+ }
Who told you/anyone who wrote this code before that the 0th lun cannot
be a real entry? This assumption is wrong.
Stefan
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC 5/5]: Rewrite findLuns function
Chris Lalancette schreef: Stefan de Konink wrote: Who told you/anyone who wrote this code before that the 0th lun cannot be a real entry? This assumption is wrong. Well, that particular piece of code isn't looking at the 0'th LUN, but there is code below that that is. However, the code here is generally looking for block devices, and the 0'th LUN is definitely not a block device. Given that, I'm not sure what else you would want to do with 0th LUN; can you give me some examples? The 0th LUN can be a perfect block device. OK, cool, I misunderstood. Given that, can you give me the output of: # ls -l /sys/bus/scsi/devices/3:0:0:0 Just to make sure I get the right thing? [EMAIL PROTECTED] ~ $ ls -l /sys/bus/scsi/devices/3:0:0:0 lrwxrwxrwx 1 root root 0 May 26 11:28 /sys/bus/scsi/devices/3:0:0:0 - ../../../devices/platform/host3/session3/target3:0:0/3:0:0:0 [EMAIL PROTECTED] ~ $ ls /sys/devices/platform/host3/session3/target3:0:0/3:0:0:0 block:sdar device_blocked genericiodone_cnt iorequest_cnt queue_depth rescan scsi_level subsystem typevendor delete driver iocounterbits ioerr_cnt model queue_type rev state timeoutuevent [EMAIL PROTECTED] ~ $ cat /sys/devices/platform/host3/session3/target3:0:0/3:0:0:0/model SOLARIS Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC 5/5]: Rewrite findLuns function
Stefan de Konink schreef: Chris Lalancette schreef: Stefan de Konink wrote: Who told you/anyone who wrote this code before that the 0th lun cannot be a real entry? This assumption is wrong. Well, that particular piece of code isn't looking at the 0'th LUN, but there is code below that that is. However, the code here is generally looking for block devices, and the 0'th LUN is definitely not a block device. Given that, I'm not sure what else you would want to do with 0th LUN; can you give me some examples? The 0th LUN can be a perfect block device. OK, cool, I misunderstood. Given that, can you give me the output of: # ls -l /sys/bus/scsi/devices/3:0:0:0 Just to make sure I get the right thing? [EMAIL PROTECTED] ~ $ ls -l /sys/devices/platform/host3/session3/target3:0:0/3:0:0:0 total 0 lrwxrwxrwx 1 root root0 May 24 16:38 block:sdar - ../../../../../../block/sdar --w--- 1 root root 4096 Jun 12 16:34 delete -r--r--r-- 1 root root 4096 Jun 12 16:34 device_blocked lrwxrwxrwx 1 root root0 May 24 16:38 driver - ../../../../../../bus/scsi/drivers/sd lrwxrwxrwx 1 root root0 Jun 12 16:34 generic - ../../../../../../class/scsi_generic/sg44 -r--r--r-- 1 root root 4096 Jun 12 16:34 iocounterbits -r--r--r-- 1 root root 4096 Jun 12 16:34 iodone_cnt -r--r--r-- 1 root root 4096 Jun 12 16:34 ioerr_cnt -r--r--r-- 1 root root 4096 Jun 12 16:34 iorequest_cnt -r--r--r-- 1 root root 4096 May 24 16:38 model -rw-r--r-- 1 root root 4096 Jun 12 16:34 queue_depth -r--r--r-- 1 root root 4096 Jun 12 16:34 queue_type --w--- 1 root root 4096 Jun 12 16:34 rescan -r--r--r-- 1 root root 4096 Jun 12 16:34 rev -r--r--r-- 1 root root 4096 Jun 12 16:34 scsi_level -rw-r--r-- 1 root root 4096 May 26 11:28 state lrwxrwxrwx 1 root root0 May 24 16:38 subsystem - ../../../../../../bus/scsi -rw-r--r-- 1 root root 4096 Jun 12 16:34 timeout -r--r--r-- 1 root root 4096 May 24 16:38 type --w--- 1 root root 4096 Jun 12 16:34 uevent -r--r--r-- 1 root root 4096 May 24 16:38 vendor -l was important ;) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC 5/5]: Rewrite findLuns function
Daniel P. Berrange schreef: Can't you distinguish based on the fact that there'll be no /dev/sdNN node for it ? You mean an explicit check for the 'block:' ? I really wonder how Linux internally distinguishes between a 'controller'. (And even more what a controller is...) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Release?
Daniel Veillard schreef: On Tue, Jun 10, 2008 at 12:40:50PM +0100, Richard W.M. Jones wrote: I've just had a chat with Daniel about whether it's time for a new release of libvirt. My own primary focus is getting the virDomain*Peek APIs into a released version so I can use them from Fedora. libvirt 0.4.2 was released on 8th Apr 2008. I just scanned the changelog and there's a pretty long list of new features: [snip] So is it time for a release? Yes, I guess it makes sense :-) I will try to push a new release before the end of the week. Do we have patches pending which should be incorporated before ? I yes please (re)push them, Can the pool.patch be incorporated before the next release? http://kinkrsoftware.nl/contrib/libvirt/pool.patch (Is probably the latest) This basically hangs on the creation of a 'test' for pools in general. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Daniel P. Berrange schreef: No, this is not developed enough. It works fine with Xen, so 'not developed' might not be the right word. The only thing that you mentioned, reverse mapping the configuration, is not a trivial problem. But this doesn't justify not including something that is working. Next to this, why should the patch be floating around, instead of importing it, in a mob branch? It doesn't support QEMU, Why doesn't QEMU use the same xml parsing routines? If you want me to add the same support to qemu_conf.c you are asking me this a bit late. it doesn't support XM, What is the difference between Xen and XM? and there's not test cases. Likewise for the rest of the storage pool commands. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkhOimMACgkQYH1+F2Rqwn3j4wCgi4NwAd+QnUNMyue65+EOOhDZ yPAAnisPr27LABsSEPJ7DfstzCSQtHuG =/QRT -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] remote access libvirtd / bindings for php/asp
What do you suggest for transparent API usage? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] remote access libvirtd / bindings for php/asp
Hi, A few people around me want to use php or asp to access libvirtd. Along this wish is to access it as 'proxy' for the entire cluster (this is where I come in). My target it to make a proxy for libvirtd that allows all host in the network to be managed by any libvirtd instance that has the sufficient certificate. Now it seems clear that this dispatch/proxy functions are doable. But what I wonder about is the actual access to libvirtd. There seems to be a pretty big warning about the XDR/ RPC calls. My people would like to see bindings to connect to libvirtd by php or asp/.net, is there any progress on that one? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] remote access libvirtd / bindings for php/asp
Richard W.M. Jones schreef: On Tue, Jun 03, 2008 at 05:27:45PM +0200, Stefan de Konink wrote: My people would like to see bindings to connect to libvirtd by php or asp/.net, is there any progress on that one? Not a lot of progress ... I looked at PHP bindings, as that is a big pain point for people who want to use libvirt in web hosting environments. I don't have a lot of time to write such bindings myself, particularly not before the Red Hat Summit. However we would support anyone who wanted to start such a project. Even binding just the common connection and domain calls (perhaps 10-15 in all) would be a great start. I think I can get motivated or get someone that is motivated or even motivate someone to write these bindings for PHP. I'll discuss the implications on friday. The problem is probably not the writing of the binding, but more getting it distributed as a stable extension. But my personal interest goes out to libvirtd overlord capabilities. By extending the API with the capability of transparently connecting to an other machine announced by avahi or added by an xml file. Or just exending libvirtd with proxy functionality. I would like to hear the Red Hat ideas on this one. So going for an 'architecture' like storage that is able to register/discover neighbor nodes. Or just sticking with an 'external' program that is able to do this task. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] remote access libvirtd / bindings for php/asp
Daniel P. Berrange schreef: On Wed, Jun 04, 2008 at 01:36:17AM +0200, Stefan de Konink wrote: Or just exending libvirtd with proxy functionality. I would like to hear the Red Hat ideas on this one. This kind of functionality doesn't really belong in libvirtd. It is not intended to be a centralized management daemon for multiple nodes. I disagree on this point. It can make the entire process a distributed effort. Operating as a single cluster, essentially the thing that lacks in XenD/KVM/etc. Without any single point of failure, connecting to any cluster node will do for management. If you want management of a whole cluster/network of machines then you want to have a separate management server talking to the libvirtd on each node and providing an aggregate view of some kind. This would mean an extra layer of complexity and again stopping people from use of the libvirt api in their applications, because this would imply that they browse their cluster theirselves, instead of looking at the cluster as one big machine, or implementing yet another new server talking its own protocol. Since libvirt already wraps xend for this problem... I don't want to have yet another daemon for the same thing: connectivity by a *good* api. libvirt isn't intended to be a complete management application in its own right - it is just providing the base infrastructure on which you can build applications. To make the application cluster aware is not something that is bad, for any application that uses it. One such application is oVirt which talks to multiple libvirtd enabled hosts and provides an aggegrate view. There are other people working on similar types of application. The problem of this external solution is that again a wrapper is required or a reimplementation of an API. The developer doesn't care if it connects to one management server or connects to some local node, he cares about the fact that it is API transparent. If I have Python/C/Ruby written for one host, and want to circumvent the problem, I would write my own methods to lookup where a VM is running. I think these capabilities OR belong to the api, which is unaware because it is not an active process, so it would need to browse first OR it should be part of libvirtd, so any libvirtd on the network can manage any libvirtd. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [Fwd: Re: [Xen-API] Retrieving XEN Server available and XEN memory]
Can we use this for libvirt too? (Free memory for Xen) Stefan ---BeginMessage--- Thanks for the quick response. -Original Message- From: Roger R. Smith [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2008 2:33 PM To: Caruso, Joseph Cc: [EMAIL PROTECTED] Subject: Re: [Xen-API] Retrieving XEN Server available and XEN memory Hi Joseph you can do something like this: $guestRef = VM.get_guest_metrics($vmRef); $getMet = VM_guest_metrics.get_record($guestRef); $getMet['memory']['free'] $getMet['memory']['total'] Hope that helps. -Rog On Fri, May 30, 2008 at 1:32 PM, Caruso, Joseph [EMAIL PROTECTED] wrote: Hello, Does anyone know how to retrieve either the amount of available server memory (not the total) or the amount of memory used by Xen? Using the host metrics object I able to retrieve both the total and free server memory. The Xen Center (see General tab) memory section displays: Server:Sun-STZENS1: 1.7 GB free of 3.7 GB available (4.0GB total) VMs: Xen:336.1 MB I want to retrieve the underlined values via the API. Thanks, Joe ___ xen-api mailing list [EMAIL PROTECTED] http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api ___ xen-api mailing list [EMAIL PROTECTED] http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api ---End Message--- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [Libvir] ISCSI howto, example, etc?
Chris Lalancette schreef: Stefan de Konink wrote: I think if you can get iscsi_sysfs.c; get_block_dev_from_lun you have the code already to do this all. So basically get openiscsi into a lib with helper functions. OK. I took a look at this further, and I figured out what is going on here. I can confirm this works for me. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Dom0 Interface stats with virDomainInterfaceStats
Daniel P. Berrange schreef: On Thu, May 22, 2008 at 04:10:22AM -0400, Daniel Veillard wrote: On Thu, May 22, 2008 at 02:53:31AM +0200, Stefan de Konink wrote: Would it be possible to enable fetch of the interface stats of the dom0 via the API? It sounds a bit Xen specific, but I see no reason why this should not be allowed. I disagree - Dom0 is a concept only present in a subset of hypervisors. What Stefan is really asking for is ability to get stats of devices in the host OS. This kind of thing belongs in a separate API such as virNodeInterfaceStats so it is usable across all our drivers. I cannot hide anything from you ;) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Compilation error (storageRegister)
Stefan de Konink schreef: ./configure --prefix=/usr --with-xen --without-sasl --without-avahi --without-test --without-libvirtd --sysconfdir=/etc --localstatedir=/var --without-qemu --without-storage-lvm --without-storage-iscsi I guess the without-libvirtd 'breaks' it. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Dom0 Interface stats with virDomainInterfaceStats
Would it be possible to enable fetch of the interface stats of the dom0 via the API? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VMware ESX
On Tue, 20 May 2008, Daniel Veillard wrote: On Mon, May 19, 2008 at 02:28:10PM -0600, drew einhorn wrote: Hi, Hi, I have some code that can probably be hacked into a libvirt driver for VMware ESX. interesting, how did you go? I did some experimentation using SOAP and gsoap2 a few weeks ago that i need to restart. Did you use VIX instead ? I read about VIX again, but is this already working for ESX? On their site and fora they mention Workstatation/Server only. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VMware ESX
On Tue, 20 May 2008, Pau Garcia i Quiles wrote: I read about VIX again, but is this already working for ESX? On their site and fora they mention Workstatation/Server only. According to http://communities.vmware.com/thread/115071 the VIX API will be supported in ESX in the future. The will be part scares me after 6 months... Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Domain XML format using defined storage volume + RFC
Daniel P. Berrange schreef:
and a volume can be either a file
or a physical device, so fixing it to be 'phy:' is not correct.
How can we know if the volume is a file or a device?
virStorageVolGetInfo() will tell you via the 'info' field of the struct
it fills
As attached. I updated the 'typ' option.
We also need to apply the reverse mapping when generating the XML. eg
do a virStorageVolLookupByPath() to discover the volume/pool.
Mmm... that sounds not trivial... (I mean duplicate wise).
This is true - until we merge all the XML processing for drivers together
there will be a non-trivial bit of duplication
Not done yet... and I prefer the last thing to be a different patch.
Stefan
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 02ca509..8e2a7b6 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -344,7 +344,7 @@
dl
dtcodedisk/code/dt
ddThe codedisk/code element is the main container for describing
- disks. The codetype/code attribute is either file or block
+ disks. The codetype/code attribute is either file, block or
pool
and refers to the underlying source for the disk. The optional
codedevice/code attribute indicates how the disk is to be exposed
to the guest OS. Possible values for this attribute are floppy, disk
@@ -354,7 +354,11 @@
ddIf the disk codetype/code is file, then the codefile/code
attribute
specifies the fully-qualified path to the file holding the disk. If the
disk
codetype/code is block, then the codedev/code attribute
specifies
- the path to the host device to serve as the disk. span
class=sinceSince 0.0.3/span/dd
+ the path to the host device to serve as the disk. If the disk
codetype/code
+is pool, then the codepool/code and codevolume/code specify the
+virtual location of the disk, the path is automatically resolved if the
pool
+and the volume exist.
+span class=sinceSince 0.0.3/span/dd
dtcodetarget/code/dt
ddThe codetarget/code element controls the bus / device under
which the
disk is exposed to the guest OS. The codedev/code attribute
indicates
diff --git a/src/xml.c b/src/xml.c
index 22dc211..598bfb3 100644
--- a/src/xml.c
+++ b/src/xml.c
@@ -1300,6 +1300,8 @@ virDomainParseXMLDiskDesc(virConnectPtr conn, xmlNodePtr
node,
typ = 0;
else if (xmlStrEqual(type, BAD_CAST block))
typ = 1;
+else if (xmlStrEqual(type, BAD_CAST pool))
+typ = 2;
xmlFree(type);
}
device = xmlGetProp(node, BAD_CAST device);
@@ -1309,11 +1311,32 @@ virDomainParseXMLDiskDesc(virConnectPtr conn,
xmlNodePtr node,
if (cur-type == XML_ELEMENT_NODE) {
if ((source == NULL)
(xmlStrEqual(cur-name, BAD_CAST source))) {
-
if (typ == 0)
source = xmlGetProp(cur, BAD_CAST file);
-else
+else if (typ == 1)
source = xmlGetProp(cur, BAD_CAST dev);
+else if (typ == 2) {
+xmlChar *pool = xmlGetProp(cur, BAD_CAST pool);
+xmlChar *volume = xmlGetProp(cur, BAD_CAST volume);
+if (pool != NULL volume != NULL) {
+virStoragePoolPtr virPool;
+virPool = virStoragePoolLookupByName(conn, (const char
*) pool);
+if (virPool != NULL) {
+virStorageVolPtr virVol;
+virVol = virStorageVolLookupByName(virPool, (const
char *) volume);
+if (virVol != NULL) {
+virStorageVolInfo info;
+if (virStorageVolGetInfo(virVol, info) == 0) {
+source = BAD_CAST
virStorageVolGetPath(virVol);
+/* We set the type to the 'native' type */
+typ = info.type;
+}
+}
+}
+}
+xmlFree(pool);
+xmlFree(volume);
+}
} else if ((target == NULL)
(xmlStrEqual(cur-name, BAD_CAST target))) {
target = xmlGetProp(cur, BAD_CAST dev);
@@ -1411,7 +1434,7 @@ virDomainParseXMLDiskDesc(virConnectPtr conn, xmlNodePtr
node,
virBufferVSprintf(buf, (uname 'phy:%s'), source);
else
virBufferVSprintf(buf, (uname 'phy:/dev/%s'), source);
-}
+}
}
if (ro == 1)
virBufferAddLit(buf, (mode 'r'));
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Domain XML format using defined storage volume + RFC
Can this be added to cvs/git? Stefan On Fri, 16 May 2008, Stefan de Konink wrote: On Thu, 15 May 2008, Stefan de Konink wrote: On Thu, 15 May 2008, Stefan de Konink wrote: I almost started crying why it didn't work. But it is fixed, and it works as a charm :) See updated patch! I guess I need to write the 'check' tool and documentation update too? Since there is currently no check build for pools in that directory, I'm passing this to someother person. Patch incorporates now a documentation update. Sign-off-by: Stefan de Konink [EMAIL PROTECTED] Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh create Guest Crashing
Chris Lalancette schreef: Kenneth Nagin wrote: Setting up new root fs setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory. setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Booting has failed. Kernel panic - not syncing: Attempted to kill init! I see two possible sources to the problem: XENBUS: Device with no driver ... and setuproot: moving /dev failed: No such file or directory ... switchroot: mount failed: No such file or directory Is there libvirt xml equivalent to the XEN configuration file's root = /dev/xvda1 ro? OK, yeah. The XENBUS: Device with no driver can be ignored, I'm pretty sure. The problem is probably what you think, that you don't have a root=/dev/xvda1 line in there. Other people will have to comment on whether there is a libvirt XML equivalent, since I'm just not sure. domain type='xen' nameGentoo/name os typelinux/type kernel/usr/lib/xen/boot/linux-2.6.20-xen-r6/kernel cmdline root=/dev/xvda ro ip=85.17.131.4:1.2.3.4:85.17.131.253:255.255.255.0::eth0:off/cmdline /os memory131072/memory vcpu1/vcpu devices disk type='pool' source pool='netapp' volume='lun-3' / target dev='xvda'/ /disk interface type='bridge' source bridge='xenbr0'/ mac address='aa:00:00:00:00:11'/ script path='/etc/xen/scripts/vif-bridge'/ /interface /devices /domain I think the target dev here can just be appended with an one? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VMware ESX
drew einhorn schreef: I have some code that can probably be hacked into a libvirt driver for VMware ESX. This shoulds cool :) I'm happy you will start this before I have to do it :) What approach will you take? Soap? Is there a template with stubs for all the necessary routines for the API that I can use as a starting point? I would take one of the existing drivers... but maybe there is a better way. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Domain XML format using defined storage volume + RFC
Daniel P. Berrange schreef:
On Fri, May 16, 2008 at 01:00:16AM +0200, Stefan de Konink wrote:
On Thu, 15 May 2008, Stefan de Konink wrote:
On Thu, 15 May 2008, Stefan de Konink wrote:
I almost started crying why it didn't work. But it is fixed, and it works
as a charm :) See updated patch!
I guess I need to write the 'check' tool and documentation update too?
Since there is currently no check build for pools in that directory, I'm
passing this to someother person.
Yes, testing the interaction with pools is actually harder that I anticipated,
because the libvirtd isn't available in context of the test suite. I'll have to
think about best way todo it. Might be able to stub out a dummy impl for
purposes
of testing.
Ok.
@@ -1309,11 +1311,24 @@ virDomainParseXMLDiskDesc(virConnectPtr conn,
xmlNodePtr node,
if (cur-type == XML_ELEMENT_NODE) {
if ((source == NULL)
(xmlStrEqual(cur-name, BAD_CAST source))) {
-
if (typ == 0)
source = xmlGetProp(cur, BAD_CAST file);
-else
+else if (typ == 1)
source = xmlGetProp(cur, BAD_CAST dev);
+else if (typ == 2) {
+xmlChar *pool = xmlGetProp(cur, BAD_CAST pool);
+xmlChar *volume = xmlGetProp(cur, BAD_CAST volume);
+if (pool != NULL volume != NULL) {
+virStoragePoolPtr virPool;
+virPool = virStoragePoolLookupByName(conn, (const char
*) pool);
+if (virPool != NULL) {
+virStorageVolPtr virVol;
+virVol = virStorageVolLookupByName(virPool, (const
char *) volume);
+if (virVol != NULL)
+source = BAD_CAST virStorageVolGetPath(virVol);
This is leaking the pool and volume objects.
Ok. Appended xmlFree's.
http://kinkrsoftware.nl/contrib/libvirt/pool.patch
+}
+}
+}
} else if ((target == NULL)
(xmlStrEqual(cur-name, BAD_CAST target))) {
target = xmlGetProp(cur, BAD_CAST dev);
@@ -1411,7 +1426,8 @@ virDomainParseXMLDiskDesc(virConnectPtr conn, xmlNodePtr
node,
virBufferVSprintf(buf, (uname 'phy:%s'), source);
else
virBufferVSprintf(buf, (uname 'phy:/dev/%s'), source);
-}
+} else if (typ == 2)
+virBufferVSprintf(buf, (uname 'phy:%s'), source);
This is leaking the 'source' string,
It is not leaking imho, since 'down under' there is an xmlFree(source).
and a volume can be either a file
or a physical device, so fixing it to be 'phy:' is not correct.
How can we know if the volume is a file or a device?
We also need to apply the reverse mapping when generating the XML. eg
do a virStorageVolLookupByPath() to discover the volume/pool.
Mmm... that sounds not trivial... (I mean duplicate wise).
Stefan
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
