Re: [libvirt] [PATCH] introducing source name (for logical storage pools)
On Tue, Sep 02, 2008 at 11:59:35AM -0400, David Lively wrote:
On Tue, 2008-09-02 at 17:54 +0200, Jim Meyering wrote:
Daniel Veillard [EMAIL PROTECTED] wrote:
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));
}
}
Hum, I'm just wondering, shouldn't we go to cleanup too on strdup
error instead of continuing there ?
You're probably right.
However, technically, it looks like having a NULL source.name there
is tolerable, since all derefs (at least in that file) first check
for non-NULL. But if a small strdup like that fails, I don't see much
point in trying to continue.
If that's the intent, then it deserves a comment explaining why this
failure case is different from most(all?) of the others in the vicinity.
Daniel is right. I meant to cleanup and exit (goto cleanup) in this
case ...
Okay, commited then !
Thanks !
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
On Tue, Sep 02, 2008 at 04:39:03PM +0200, Alejandro Berna Juan wrote: Hi Daniel, all, I'm sorry for my non show during the summer but I was in my long holidays ;) No problem, I'm french I know what real summer vacations means :-) 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. okay, cool. 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, As Dan Smith pointed out this is available separately as the libvirt-cim package/releases . It really should be language agnostic because CIM defines itselt in term of RPCs to the node. 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] Live migration sanity checks
On Wed, Sep 03, 2008 at 09:22:50AM -0400, Konrad Rzeszutek wrote: On Wed, Sep 03, 2008 at 01:53:44PM +0100, Daniel P. Berrange wrote: On Wed, Sep 03, 2008 at 08:43:44AM -0400, Konrad Rzeszutek wrote: 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. I am interested to know why you think this is a no-no. If you have a set of hosts and you want to be able to migrate between all of them and your shared storage is iSCSI why would it make a difference whether you had logged in or logged in on the migrate on each host? In the general case it is a needless scalability bottleneck. If you have 50 iSCSI targets exported on your iSCSI server, and 1000 hosts in the network, So in the context of oVirt the question of iSCSI connectivity may be a non-issue. In the context of libvirt, we cannot assume this because its a policy decision of the admin / application using libvirt. Sure. Isn't the code providing a GUID for the iSCSI pool so that before a migrate, the nodes can compare their GUIDs to find a match? And if not, complain so that the admin would create a pool. Which is exactly the point I made in my first mail. If you're checking for migration compatability between 2 hosts, and then for some guest configurations (of which iSCSI is just one example), you've got an external setup dependancy there which the application doing migration has to deal with quite early on. 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
Re: [libvirt] [PATCH] Attempt to detect cdrom change failures
Cole Robinson wrote:
If a 'change' or 'eject' qemu monitor command fails,
an error message is printed to the monitor of the
form device {not found, is locked, is not
removable}. This is really the only indication we
have that the command errored out, so scrape the
monitor reply for \ndevice and fail if it is
found.
Thanks,
Cole
I've committed this.
Thanks,
Cole
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] virConnectListAllDomains (version 3, still no Xen)
This is a third version of the virConnectListAllDomains patch. The API is now slightly different from previous proposals. We only allow filtering on All/Active/Inactive, and not by a long list of fine-grained states. The reason is twofold: (1) a simpler implementation and (2) doubtful that anyone would actually use the fine-grained filtering feature. The new API is shown below. I have tested this out with mlvirsh and virt-top and of course in the remote case there is a substantial saving in terms of round-trip times, although it's hard to precisely measure what the difference is when I've got only a couple of guests running. There is still no Xen-specific implementation, but note that in the remote case you get some of the benefit anyway. Rich. -- /** * virConnectListAllDomains: * @conn: pointer to the hypervisor connection * @domains: pointer to returned array of domain pointers (must not be NULL) * @infos: pointer to returned array of virDomainInfo structures (may be NULL) * @stateflags: state of domains of interest * @flags: other flags (always 0) * * This call returns the list of all domains, active or inactive, * and their virDomainInfo structures. * * This call is usually more efficient than using the old method * of calling virConnectListDomains and virConnectListDefinedDomains * and then loading each domain and its info. This call is supported * for all hypervisor types. (If the backend driver doesn't support it * directly, then the call is emulated for you). * * @stateflags allows only the domains of interest to be * returned. Callers must pass one of: * VIR_DOMAIN_LIST_ACTIVE to return running domains, * VIR_DOMAIN_LIST_INACTIVE to return defined but not running domains, * VIR_DOMAIN_LIST_ALL to return all domains, * 0 to return no domains. * * @flags may be used in the future. Always pass 0 for this parameter. * * If there is no error then @domains will be updated to point to an * array of virDomainPtr. * * If there is no error and @infos is not NULL, then @infos will be * updated to point to an array of virDomainInfo structures, with * the same length as the array of domains. * * Returns the number of domains in the @domains array, or -1 in * case of error. * * If there was no error then the caller must free each domain * with virDomainFree, free the array of @domains pointers, * and if necessary free the array of @infos structures. */ int virConnectListAllDomains(virConnectPtr conn, virDomainPtr **domains, virDomainInfo **infos, unsigned long stateflags, unsigned long flags); -- -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora Index: include/libvirt/libvirt.h.in === RCS file: /data/cvs/libvirt/include/libvirt/libvirt.h.in,v retrieving revision 1.53 diff -u -r1.53 libvirt.h.in --- include/libvirt/libvirt.h.in27 Aug 2008 20:05:58 - 1.53 +++ include/libvirt/libvirt.h.in3 Sep 2008 15:43:56 - @@ -75,6 +75,11 @@ VIR_DOMAIN_CRASHED = 6 /* the domain is crashed */ } virDomainState; +/* For virConnectListAllDomains. */ +#define VIR_DOMAIN_LIST_ACTIVE 1 +#define VIR_DOMAIN_LIST_INACTIVE 2 +#define VIR_DOMAIN_LIST_ALL (VIR_DOMAIN_LIST_ACTIVE | VIR_DOMAIN_LIST_INACTIVE) + /** * virDomainInfoPtr: * @@ -417,6 +422,15 @@ unsigned long long virNodeGetFreeMemory(virConnectPtr conn); /* + * New-style list-all-domains call. + */ +int virConnectListAllDomains(virConnectPtr conn, + virDomainPtr **domains, + virDomainInfo **infos, + unsigned long stateflags, + unsigned long flags); + +/* * Gather list of running domains */ int virConnectListDomains (virConnectPtr conn, Index: qemud/remote.c === RCS file: /data/cvs/libvirt/qemud/remote.c,v retrieving revision 1.39 diff -u -r1.39 remote.c --- qemud/remote.c 27 Aug 2008 20:05:59 - 1.39 +++ qemud/remote.c 3 Sep 2008 15:43:59 - @@ -1904,6 +1904,71 @@ } static int +remoteDispatchListAllDomains (struct qemud_server *server ATTRIBUTE_UNUSED, + struct qemud_client *client, + remote_message_header *req, + remote_list_all_domains_args *args,
[libvirt] [PATCH] Two safer versions of virDomainGetID
Two alternative versions of a safer virDomainGetID call in followups to this message. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH alternative 1/2] virDomainGetID2
This adds virDomainGetID2 which uses a pointer to int parameter, allowing the -1 (non-running) domain ID to be returned safely. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones 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/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH alternative 2/2] Change contract of virDomainGetID to make it safer
This changes the contract of the existing virDomainGetID call so that it is guaranteed to return the ID provided that the @domain parameter is not NULL or corrupted. This should be compatible with all preceeding versions of libvirt, since all they have ever done is to check the @domain parameter and return the dom-id field. However it might not be forwards compatible with future versions: At the moment there is an odd distinction between the local and remote case. In the local case, the dom-id field is set to -1 when the domain goes (mostly anyhow, not always). In the remote case it is not set, because this is not known. In practice, this never really matters. All significant libvirt callers grab a new virDomain object from the remote end each time, thus getting an updated ID. virDomain objects seem to be individually very short-lived. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora Index: src/libvirt.c === RCS file: /data/cvs/libvirt/src/libvirt.c,v retrieving revision 1.155 diff -u -r1.155 libvirt.c --- src/libvirt.c 2 Sep 2008 15:00:09 - 1.155 +++ src/libvirt.c 3 Sep 2008 16:16:47 - @@ -1878,7 +1878,9 @@ * * Get the hypervisor ID number for the domain * - * Returns the domain ID number or (unsigned int) -1 in case of error + * Returns the domain ID number or (unsigned int) -1 if the domain is + * not running. If @domain is NULL or its memory is corrupted + * then this can also return (unsigned int) -1. */ unsigned int virDomainGetID(virDomainPtr domain) -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Add a augeas lens for libvirtd.conf
On Wed, Aug 27, 2008 at 12:04:17PM +0100, Richard W.M. Jones wrote: On Tue, Aug 26, 2008 at 09:05:37PM +0100, Daniel P. Berrange wrote: Augeas is a awesome config file manipulation tool. libvirtd has a config file. libvirtd meet augeas; augeas meet libvirt. Now instead of telling people 'edit /etc/libvirt/libvirtd.conf and change listen_tls to 1, and auth_tls to sasl' we can say run # augtool EOF set /files/etc/libvirt/libvirtd.conf/listen_tls 1 set /files/etc/libvirt/libvirtd.conf/auth_tls sasl save EOF THis patch is intended to be committed to libvirt, so the config file rules are distributed alongside libvirt. I'm CC'ing augeas-devel for feedback on the lens itself. libvirt.spec.in |2 qemud/Makefile.am |8 qemud/libvirtd.aug | 64 ++ qemud/test_libvirtd.aug | 484 4 files changed, 558 insertions(+) +1, to the general concept, and the code apart from the lens itself which I didn't look at too closely. Same thing, I like the idea and if David agrees with the .aug files and changes then I guess this should be commited, 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] Libvirtd needs to be always running/
Hi, Yao You should differenciate Qemu and Xen(zen). For QEMU, libvirtd need to run always. For Xen, it does not requrired to run for local machine. and required to run for remote machine. Thanks Atsushi SAKAI Yushu Yao [EMAIL PROTECTED] wrote: Hi All, A newbie question: Does the libvirtd need to be running all the time if I want to use any functions of libvirt (as simple as start/stop/pause my virtual machines (qemu/zen)). Or is it only try if I use the remote functions or virsh. Thanks, -Yushu -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Libvirtd needs to be always running/
Thanks Atsushi and Stefan, It seems that libvirtd has to run with root, is this true? 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? Thanks! -Yushu On 9/3/08 6:08 PM, Stefan de Konink [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Atsushi SAKAI schreef: You should differenciate Qemu and Xen(zen). For QEMU, libvirtd need to run always. For Xen, it does not requrired to run for local machine. and required to run for remote machine. Some people still have their hopes that libvirtd will do the same for Xen in the near future :) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAki/NP8ACgkQYH1+F2Rqwn32awCXdiNGVwZWj3dEA526BZDOM2Zh qwCeOGf7fQmG9pzG7tKKuuL7ZzMT18c= =+umj -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/
Yushu Yao [EMAIL PROTECTED] wrote: Thanks Atsushi and Stefan, It seems that libvirtd has to run with root, is this true? 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? Please see follows https://www.redhat.com/archives/libvir-list/2008-September/msg5.html Thanks! -Yushu On 9/3/08 6:08 PM, Stefan de Konink [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Atsushi SAKAI schreef: You should differenciate Qemu and Xen(zen). For QEMU, libvirtd need to run always. For Xen, it does not requrired to run for local machine. and required to run for remote machine. Some people still have their hopes that libvirtd will do the same for Xen in the near future :) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAki/NP8ACgkQYH1+F2Rqwn32awCXdiNGVwZWj3dEA526BZDOM2Zh qwCeOGf7fQmG9pzG7tKKuuL7ZzMT18c= =+umj -END PGP SIGNATURE- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] xen: fix domain lookup after define
On Thu, Aug 28, 2008 at 10:19:01AM +0100, Daniel P. Berrange wrote: On Wed, Aug 27, 2008 at 08:57:24PM -0400, Cole Robinson wrote: Defining a xen domain will succeed, but report error because we weren't properly passing the domain's name to the post-define lookup. ACK, this was a mistake during the conversion to new APIs Attached patch fixes this, and also adds a debug statement to show the sexpr we create from the passed xml. Good idea - there's been a number of BZ tickets where it would have been useful to ask the user to get this with LIBVIRT_DEBUG=1 Agreed, looks fine to me, +1 ! 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
[libvirt] [PATCH] Fix signedness bug in src/qemu_driver.c
Fix a signedness bug in src/qemu_driver.c, qemuCmdFlags needs to be
unsigned int.
Signed-off-by: James Morris [EMAIL PROTECTED]
---
src/qemu_driver.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 59faf94..72c2d81 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2987,7 +2987,7 @@ static int qemudDomainChangeEjectableMedia(virDomainPtr
dom,
virDomainDiskDefPtr origdisk, newdisk;
char *cmd, *reply, *safe_path;
char *devname = NULL;
-int qemuCmdFlags;
+unsigned int qemuCmdFlags;
if (!vm) {
qemudReportError(dom-conn, dom, NULL, VIR_ERR_INVALID_DOMAIN,
--
1.6.0.1
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix vnc port determining for xend
On Thu, Aug 28, 2008 at 04:48:06PM -0400, Cole Robinson wrote: Current libvirt checks xenstore for a xen guests fixed vnc port on xend 3.0.3. At least on f8 though, hvm guests don't store the vnc port in xenstore, it is stored in the sexpr. Patch fixes the logic to look in the sexpr if the xenstore lookup appears to fail. This fixes setting static vnc ports for f8 xen hvm guests. Sounds fine to me though I winder if it's not better to check on the given SExpr first and then do a Xenstore lookup only if needed. Seems to me a more generally coherent approach, any expected drawback to this ? 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] LXC: making the private root filesystem more secure
On Thu, Aug 28, 2008 at 11:56:58PM +0100, Daniel P. Berrange wrote:
When I wrote the private root filesystem stuff for LXC (which I just
committed) I noted that we couldn't actually make this secure, because
someone inside the chroot can just 'mknod' and access the host devices.
What I completely forgot was that cgroups as of 2.6.26 has device ACLs
If we place every container in a cgroup (which was planned anyway), then
we can trivially prevent containers accessing host devices
One time setup
mount -t cgroups /dev/cgroups
mkdir /dev/cgroups/libvirt
mkdir /dev/cgroups/libvirt/lxc
For each new container 'NAME'
mkdir /dev/cgroups/libvirt/lxc/{NAME}
echo a /dev/cgroups/libvirt/lxc/{NAME}/devices.deny
echo c 1:3 rwm /dev/cgroups/libvirt/lxc/{NAME}/devices.allow
echo c 1:5 rwm /dev/cgroups/libvirt/lxc/{NAME}/devices.allow
echo c 1:7 rwm /dev/cgroups/libvirt/lxc/{NAME}/devices.allow
echo c 5:1 rwm /dev/cgroups/libvirt/lxc/{NAME}/devices.allow
echo c 1:8 rwm /dev/cgroups/libvirt/lxc/{NAME}/devices.allow
echo c 1:9 rwm /dev/cgroups/libvirt/lxc/{NAME}/devices.allow
This denies all devices, and then allows null, zero, full, console, random
and urandom. Allowing use of 'random' is debatable.
Sounds fine to me, the first 4 sounds unavoidable, for (u)random I
guess that will be needed for most setup but there we are at the limit
of libvirt, i.e. start to step on the policies for the guests
The 'devpts' namespace stuff is also needed to provide private PTYs.
The 'user' namespace stuff is needed to prevent an unprivileged user
in the host OS from killing off processes with same UID inside the
container. There looks to be active patchsets for both of these being
discussed, so we're getting close to having a genuinely useful
container based virt driver with LXC
Which is something I would love to see for Fedora 10, possibly as an
update.
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
