[libvirt] Libvirt Packaged Linux Distributions
Guys, Can anyone give me list of Linux enterprise editions distributions that are packaged with xyz version of libvirt? Regards, Atif -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Libvirt Packaged Linux Distributions
On Tue, Sep 02, 2008 at 09:26:09AM +0200, atif bajwa wrote: Guys, Can anyone give me list of Linux enterprise editions distributions that are packaged with xyz version of libvirt? RHEL-5.0 has libvirt 0.1.8 RHEL-5.1 has libvirt 0.2.3 RHEL-5.2 has libvirt 0.3.3 Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.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
[libvirt] Reminder about developer IRC channel
There're a few new people contributing patches to libvirt recently, so just thought I'd remind people that many of us hang out on IRC. The channel is #virt on irc.oftc.net. If we seem to be ignoring patches[1] you've sent, then do send nag-emails to this list, or say hello on IRC to ask about the status of things (most of us are currently on a European timezone) Regards, Daniel [1] We're not delibrately ignoring them - things just get missed / forgotten / delayed sometimes due to other things we work on. -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.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
Re: [libvirt] [PATCH] introducing source name (for logical storage pools)
On Fri, Aug 29, 2008 at 03:49:27PM -0400, David Lively wrote: Hi Jim - I've attached a (very) small incremental patch (i.e., to be applied after the one you've already merged) that addresses a couple things I noticed missing: (a) documents the new source name element in formatstorage.html.in (b) adds --source-name to the (optional) args for virsh pool-define-as I've also attached a new version of the full patch containing this change, in case that's easier. Okidoc, I finally added this in CVS, i just had to do a bit of porting since the XPath lookup function have an extra argument, but nothing hard. I also changed some of the error message to provide more context because as Jim pointed out they were a bit too generic. thanks a lot ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ [EMAIL PROTECTED] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Java bindings
Hi Daniel, all, I'm sorry for my non show during the summer but I was in my long holidays ;) I will have the libvirt project for Eclipse with the libvirt java bindings during this month, if I use as a base the makefile it wouldn't be too complicate to generate. Also I would like to ask you (because we need for our Federica project) if libvirt is using CIM model or is using something similar. I read that is collaborating with DMTF but we have not found anything that tells that libvirt is using CIM model. If you don't know exactly can you tell me who to contact to assure this? I hope you can help me, thank you for everything, Cheers, Alejandro 2008/7/22 Daniel Veillard [EMAIL PROTECTED] On Mon, Jul 21, 2008 at 08:58:31AM +0200, Alejandro Berna Juan wrote: my idea is to create the eclipse project (I have a little experience with it and I think I can do it). Right now is a little bit complicate to help you in the generation of code (I'm new in XEN and virtualization). Cheers, that would be cool, yes. I finally added some informations on-line at http://libvirt.org/java.html I don't know why the javadoc output seems to be missing frames or something (using a java-1.5.0-ibm javadoc ...), but at least the basic is there http://libvirt.org/org/libvirt/package-summary.html Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Alejandro Berna Juan [EMAIL PROTECTED] -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] introducing source name (for logical storage pools)
Thanks Daniel. I just merged in your changes. You seem to be missing a
small incremental change (checking the strdup return value for NULL),
attached.
Dave
On Tue, 2008-09-02 at 16:17 +0200, Daniel Veillard wrote:
On Fri, Aug 29, 2008 at 03:49:27PM -0400, David Lively wrote:
Hi Jim -
I've attached a (very) small incremental patch (i.e., to be applied
after the one you've already merged) that addresses a couple things I
noticed missing:
(a) documents the new source name element in formatstorage.html.in
(b) adds --source-name to the (optional) args for virsh pool-define-as
I've also attached a new version of the full patch containing this
change, in case that's easier.
Okidoc, I finally added this in CVS, i just had to do a bit of porting
since the XPath lookup function have an extra argument, but nothing
hard. I also changed some of the error message to provide more context
because as Jim pointed out they were a bit too generic.
thanks a lot !
Daniel
diff --git a/src/storage_conf.c b/src/storage_conf.c
index 2f6093b..37a2040 100644
--- a/src/storage_conf.c
+++ b/src/storage_conf.c
@@ -331,6 +331,8 @@ virStoragePoolDefParseDoc(virConnectPtr conn,
if (ret-source.name == NULL) {
/* source name defaults to pool name */
ret-source.name = strdup(ret-name);
+if (ret-source.name == NULL)
+virStorageReportError(conn, VIR_ERR_NO_MEMORY, %s, _(pool name));
}
}
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Live migration sanity checks
CL I also want to see what KVM does here; however, I don't think that CL prevents us from implementing our own, since we would still need CL similar things for other hypervisors (Xen, etc.). Right, I think it's important to include the possibility for the hypervisor to do its own check. Since you mentioned the need for the user to specify a list of allowable checks, perhaps ask the hypervisor too could be one of those. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [EMAIL PROTECTED] pgpSwMH7W9SYM.pgp Description: PGP signature -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvir: Xen error
Alain, According to Ricahrd this error should be fixed in the RHEL v5.3, Hence the THANK YOU for taking the time look at the errors and sharing his openion. Regards, umantra On 9/1/08, Alain Barthe [EMAIL PROTECTED] wrote: 2008/8/28 mantra UNIX [EMAIL PROTECTED] Thank you Richard. Thank you for what ? If you got an answer off list, please share it, I have the same problem and got no solutions. Best regards. Alain. On 8/27/08, Richard W.M. Jones [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 02:30:37PM -0500, mantra UNIX wrote: Hello everyone, I get the following error when i try to redtart a domain; # virsh list libvir: Xen error : Domain not found: xenUnifiedDomainLookupByID I am using RHEL5.2 on i386, I have searched for the error on web and on RedHat but could not find any. The bug report is a bit unclear. How did you restart the domain? (eg. from inside the guest? using a virsh command?) Did you wait after restarting the domain? Can you also post the output of: xm list --long Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones http://et.redhat.com/%7Erjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/http://et.redhat.com/%7Erjones/virt-df/ -- Regards, mantra - Instrument of Thought -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Regards, mantra - Instrument of Thought -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Live migration sanity checks
On Tue, Sep 02, 2008 at 07:38:59AM +0200, Chris Lalancette wrote: Richard W.M. Jones wrote: On Fri, Aug 29, 2008 at 10:44:50AM +0200, Chris Lalancette wrote: Things that I've missed? Maybe a good place for this list is on the wiki? On the actual feature/todo page. I'd like to see where KVM is going to go with this, since it seems they are going to implement migration checking. Yes, OK, I've put that there now. I also want to see what KVM does here; however, I don't think that prevents us from implementing our own, since we would still need similar things for other hypervisors (Xen, etc.). Following on from this, there are some things it is simply not practical for the underlying hypervisor to check for itself - specifically things that require knowledge outside the scope of the HV. For example, how would the hypervisor ever know whether /dev/sda1 on the source box was the same as /dev/sda1 on the destination box. This information is only available at a higher level. Indeed for some of this, even libvirt can not answer the question, and oVirt would have to make decisions directly. Looking at Chris' list of things to check for I think one thing is very clear - a simple boolean test is not a useful API model at the libvirt, let alone the hypervisor level. There are a series of items that need to be checked. Some may appear have a straight yes/no answer, but in fact the eventual decision is a matter of application policy. For example it may seem 'obvious' that you cannot migrate a i386 guest from an x86_64 host onto a PPC64 host. This would be a bad assumption though, because you may be quite happy to run it on the destination host under QEMU's x86_64 or i686 emulator. Whether such a migration is acceptable is totally dependant on the SLA requirements of the application running inside the guest. So you have a simple yes/no answer, but with multiple values of 'yes', some better than others. In other cases you may not be able to produce a yes/no answer, having to apply heuristics. A hueristic may have a firm negative, and a probable positive; a probable negative and a firm positive; a probable negative and a probably positive. For example, checking CPU flag compatability. If the source has SSE3, and the destinatio nonly have SSE2, you may or may not be safely able to migrate depending on whether any app in the guest has probed for is using SSE3 instructions. Most mgmt tools will just be conservative in this scenario and refuse to migrate. Or they will mask CPU flags to lowest-common denominator. Another example is a guest whose disks are on firewire/usb storage. You can check this and if /dev/sda on the source destination has different model/vendor/serial you can say they're different disks. If they are the same model/vendor/ serial they may or may not be the same physical disks - it is possible to get multi-homed firewire disks even if its not common. There is also a problem of race conditions in the checking vs action. A guest is using 1 GB of ram, and needs to be on a dedicated NUMA node with 1 GB ram free. Between the time of performing the check and the guest being migrated the situation may have changed - other guests may have auto-ballooned up/down, the kernel itself may have consumed memory on the desired NUMA node for its own purposes (disk/io caches), or other user apps may have used/released memory. So we can say there's probably enough free memory for the guest to migrate and have all its allocations on a single node, but we can't easily guarentee it. Do we apply some safety margin in our checks ? eg, check for 1.2 GB free if the guest requires 1 GB ? Do we check, and then pre-reserve it, and then check again before migrating. Or just accept that some migrations will fail and make damn sure the VM is guarentee to keep running safely on its original host. Or all of the above Finally there is a problem of some compatability factors requiring some amount of host 'setup'. If a guest is using iSCSI as its storage, then there is a step where the host has to login to the iSCSI target and create device nodes for the LUNs before the guest can be run. You don't want every single host to be logged into all your iSCSI targets all the time. So what do you do for your migration check wrt to iSCSI ? Do you just check that both hosts can access the same iSCSI server + target ? That might not detect LUN masking/zoning well enough. So you probably need to actually do all the iSCSI setup on the target before doing the migrate compatability check. And if you decide not to migrate after that, you'll want to tear the iSCSI stuff down again. This all makes it very hard to think of an API for 'checking' migration compatability between 2 hosts. The best option I can think of is something along the lines of having the application provide a list of 'facts' it wants checked, and getting back a list of answers one per fact, with a set of values 'no', 'yes', 'probably-yes',
[libvirt] remote_protocol.{c,h} ?
Hi,
Is it really true that qemud/remote_protocol.{c,h} are created by
rpcgen? If so, why dont we have them created at compile time? I still
see them in the source code.
I modified remote_protocol.x a bit, and when recompiling,
remote_protocol.{c,h} are not reflected at all. So it is expected that
developers must recompile with rpcgen themself??
Thanks,
Jun
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: remote_protocol.{c,h} ?
On Wed, Sep 3, 2008 at 1:00 PM, Jun Koi [EMAIL PROTECTED] wrote:
Hi,
Is it really true that qemud/remote_protocol.{c,h} are created by
rpcgen? If so, why dont we have them created at compile time? I still
see them in the source code.
I modified remote_protocol.x a bit, and when recompiling,
remote_protocol.{c,h} are not reflected at all. So it is expected that
developers must recompile with rpcgen themself??
I looked again, and see that we can generate remote_protocol.c from
rpcgen. Currently it seems remote_protocol.c is hacked a bit to remove
some unused stack variables? Why do we need to do such a thing, while
compiler can optimize that for us?
So I guess it is better to have rpcgen does all the job, and leave
everything as it is. We can rename remote_protocol_xdr.c to
remote_protocol.c if you still insist that (but I see no good reason
to do so).
Thanks,
Jun
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
