You may consider 32-bit a dead technology, but we do not. We have one 32-bit application that runs and collects configuration and performance data for all types of Linux based system regardless if it is 32-bit or 64-bit. Until such time as there is no 32-bit systems, I do not see this going away anytime soon.
I can understand that libvirt is not too concerned about the internal of the guest, but for our purposes, it is a concern. While having the uptime (which is available from xm) and hostname (a nice to have), the reporting of the real operating system without forcing the user to deploy agents into each and every guest just to obtain this sort of basic information about it. The operating system is of importance to us for use cases like server/workload consolidation where you need to know if the workload from one system can indeed be migrated to another, where the first factor is are they running the same operating systems. This is something to keep in mind. John -----Original Message----- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: Friday, August 20, 2010 8:58 AM To: Tavares, John Cc: libvir-list@redhat.com; Tomen Tse; Betley, Greg; Chen, Jianjiun Subject: Re: [libvirt] inability to open local read-only connection On Fri, Aug 20, 2010 at 07:42:32AM -0500, Tavares, John wrote: > If you don't mind, I have a few other questions related to > this that I'd like to ask before I forget about them. > > 1) Is there any technical reason for not shipping the 32-bit > version of the libvirt shared library for 64-bit systems?? The libvirt RPC protocol is arch-invariant, so you can use a 32-bit libvirt library to talk to a 64-bit host, and vica-verca. So you can install the 32bit library if desired, but really 32-bit is dead technology, so its better to just recompile any apps for 64-bit. > 2) Is it possible via libvirt to get that some additional > information about the guests, such as: > a) uptime > b) hostname > c) real operating system You can't reliably get any of that information without having an agent running inside the guest OS. Currently libvirt does not concern itself with guest agent services, the focus being primarily on host OS management. There's a small chance this may change in the future, but its too early to say for sure. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
