[libvirt] OpenVZ : The restriction of domain name should be addressed
Hi, The current libvirt OpenVZ driver has a restriction that the domain names must match the OpenVZ container VEID I really want to have domain name as character, not integer. It could help me very much if any patch against this problem would be released. Is there anyone tackling this problem now?( or going to? ) Otherwise, any hint would help me. Regards. - Yuji Nishida nish...@nict.go.jp -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] docs: say that the old repository is deprecated...
I've just officially deprecated the original cvs-to-git-mirror libvirt repository on et.redhat.com, by git-removing all files and adding one with a pointer to the new repository: http://git.et.redhat.com/?p=libvirt.git;a=commitdiff;h=2940bc0fa9f2a3 Here's the corresponding change to update libvirt's web documentation: From 521ac5174827400804d33e219ce02e6bd3da1089 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Fri, 24 Jul 2009 10:57:39 +0200 Subject: [PATCH] docs: say that the old repository is deprecated... * docs/downloads.html.in: but will remain for sake of old links. --- docs/downloads.html.in |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/downloads.html.in b/docs/downloads.html.in index 0d2adb4..a34ddd1 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -74,9 +74,10 @@ p Jim Mereying was maintaining a CVS to git mirror on a href=http://git.et.redhat.com/?p=libvirt.git;git.et.redhat.com/a. - Existing users should migrate to the new git server, as the - old one will be deprecated and turned into a mirror of the - libvirt.org one. It's available as: + Existing users should migrate to the new libvirt.org git server, as the + old one is now deprecated. For the sake of old links including now- + rewritten SHA1s, we'll leave the old repository on-line for some time. + It is available as: /p pre -- 1.6.4.rc2.182.g24de1 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] docs: say that the old repository is deprecated...
On Fri, Jul 24, 2009 at 10:59:46AM +0200, Jim Meyering wrote: I've just officially deprecated the original cvs-to-git-mirror libvirt repository on et.redhat.com, by git-removing all files and adding one with a pointer to the new repository: http://git.et.redhat.com/?p=libvirt.git;a=commitdiff;h=2940bc0fa9f2a3 Here's the corresponding change to update libvirt's web documentation: ACK, makes sense to me ! thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | 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] [PATCH] docs: say that the old repository is deprecated...
Daniel Veillard wrote: On Fri, Jul 24, 2009 at 10:59:46AM +0200, Jim Meyering wrote: I've just officially deprecated the original cvs-to-git-mirror libvirt repository on et.redhat.com, by git-removing all files and adding one with a pointer to the new repository: http://git.et.redhat.com/?p=libvirt.git;a=commitdiff;h=2940bc0fa9f2a3 Here's the corresponding change to update libvirt's web documentation: ACK, makes sense to me ! Thanks. pushed -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/9] Add volume encryption information handling.
On Fri, Jul 24, 2009 at 12:08:32AM -0400, Miloslav Trmac wrote:
- Daniel P. Berrange berra...@redhat.com wrote:
On Tue, Jul 21, 2009 at 01:11:57PM +0200, Miloslav Trma?? wrote:
+#include stdbool.h
+#include libxml/tree.h
+
+enum virStorageEncryptionFormat {
+VIR_STORAGE_ENCRYPTION_FORMAT_UNENCRYPTED = 0,
+VIR_STORAGE_ENCRYPTION_FORMAT_QCOW, /* Both qcow and qcow2 */
+
+VIR_STORAGE_ENCRYPTION_FORMAT_LAST,
+};
+VIR_ENUM_DECL(virStorageEncryptionFormat)
+
+typedef struct _virStorageEncryption virStorageEncryption;
+typedef virStorageEncryption *virStorageEncryptionPtr;
+struct _virStorageEncryption {
+int format;/* enum virStorageEncryptionFormat */
+
+union {/* Format-specific data */
+struct {
+char *passphrase;
+} qcow;
+} v;
+};
As with the XML format, I'd like to avoid encoding qcow as a
structural element here. Instead go for a generic storage of
secrets.
enum virStorageEncryptionSecret {
VIR_STORAGE_ENCRYPTION_SECRET_PASSPHRASE,
};
struct virStorageSecret{
int type;/* enum virStorageSecret */
union {
char *passphrase;
} data;
};
struct _virStorageEncryption {
unsigned encrypted : 1;
int nsecrets;
virStorageSecret *secrets;
}
This allows for 1 secret should we need that (eg, for
LUKS/cryptsetup volume)
As argued in the 0/9 e-mail, the encryption format is an independent
piece of information that needs to be stored, and the set of other
information that needs to be stored can differ among formats. Should
we ever need support for more than one secret in LUKS, that a separate
struct { ... } luks should be added to the union: it seems to me that
support for storing more than one passphrase is not necessary for
libvirt's use of LUKS (although LUKS supports it) - on the other hand,
if such support would be necessary, it would most likely be necessary
to store the slot used by each passphrase as well.
For the domain XML I agree that libirt would not need to worry about
multiple LUKS keys, but for the storage volume XML we would need to
expose the fact that there are multiple keys,or allow creation of
volumes with multiple keys.
We know that the type and amount of information that will need to be
stored will vary depending on the encryption format; on the other
hand, expecting that the information consists of independent secrets,
each with a simple and format-independent definition, is probably too
optimistic. (As mentioned above, we might need a key slot ID associated
with a LUKS passphrase; we might also need a password hash algorithm
associated with a dm-crypt passphrase. The encryption formats used in
practice are often complex enough that a simple passphrase can not
be used.) Once we have to assume that each secret can have an encryption
format-dependent format, I think it is much clearer to use something like
The idea of a 'key slot' and 'password hash algorithm' are not neccessarily
unique to LUKS though. If we get 2 different encryption formats both requiring
the concept of a 'key slot' we need to represent them in the same way in the
XML, not hve a different XML for each format.
enum { FORMAT_1, FORMAT_2, FORMAT_3 } format;
union {
struct { char *secret_1; } format_1;
struct { struct { char *secret, id; } secrets[N]; } format_2;
struct { int param_1, param_2, param_3; char *secret_1, *secret_2 };
format_2;
}
which explicitly defines what information is requested for each format,
and how it is related, (and which allows showing the data related to a
single format in a debugger by simply choosing a single member of the
union) than something like
struct {
enum { SECRET_FMT_1, SECRET_FMT_2, PARAM_FMT_1, PARAM_FMT_2 } type;
union {
char *secret_fmt_1;
struct { char *secret, id} secret_fmt_2;
int param_fmt_1;
char *param_fmt_2;
}
} [...]
with implicit assumptions about the secret and parameter formats used
by various encryption formats.
This makes life very hard for libvirt clients, because it implies that
every single new disk encryption format we add, results in new XML
elements being added, which pushes a significant burden onto clients
which want to use encryption, because they now have to be aware of
multiple different ways of representing the same fundamental concepts.
Even if the XML uses one or more generic-looking secret elements, the
information will have to be categorized depending on its meaning and
relations before being used; it seems to me cleaner to do it once, when
parsing the XML, than to parse the XML without assigning much semantic
value to it, and then re-parse the internal representation to categorize
the information.
Categorizing the information already when parsing the XML will
Re: [libvirt] [PATCH 0/9] Add support for (qcow*) volume encryption
On Thu, Jul 23, 2009 at 11:43:09PM -0400, Miloslav Trmac wrote: The encryption tag can be added to a volume node passed to virStorageVolCreateXML() to create an encrypted volume, or to a disk node inside a domain to specify what encryption parameters to use for a domain. If the domain is persistent, the parameters (including the passphrase) will be saved unencrypted in /etc/libvirtd; the primary use case is to store the parameters outside of libvirtd, (perhaps by virt-manager in a GNOME keyring). - Support for dumb clients that don't know anything about encryption formats and the required parameters: adding an encryption format to libvirt would automatically make it supported in all clients. Such a client would only request that a volume should be created when creating it, and libvirt would choose an appropriate format, parameters and passphrase/key and return it to the client, who could later pass it unmodified inside a domain. This requires public API additions to let libvirt return the encryption information as one of the results of a volume creation operation. - Support for storing the passphrases/keys used by persistent domains outside of the main XML files, e.g. in a separate passphrase-encrypted file that must be entered on libvirtd startup. I think these two points overlap quite alot. Not quite: the main case of a dumb client would be a large-scale virtualization management software that contains a primary store of encryption information, and gives each node access only to those keys that are currently necessary by the node to run its domains; the fact that each node has access to only a limited set of keys prevents an attacker that compromises a single node from reading disk images of all domains managed in the entire site, even if the disk image storage (e.g. unencrypted NFS) does not allow managing access by each node separately. Such a client must be able to transfer the actual secrets, not only identifiers, to libvirt. (The idea of a dumb client, that does not know the specifics of the format, is an additional feature on top, but one that implies that the client does send the actual secrets.) This implies a flow of secrets Key server --\ +- libvirt client - libvirt daemon - qemu MGMT server --/ This does not in fact guarentee that secrets for a particular node are only used on the node for which they are intended, because the key server cannot be sure of what libvirt daemons the libvirt client is connected to. What I am suggesting is that libvirt daemon should communicate with the key server directly in all cases, and take the client out of the loop. The client should merely indicate whether it wants encryption or not, and never be able to directly access any key material itself. With a direct trust relationship between the key server and each libvirtd daemon, you do now have a guarentee that keys are only ever used on the node for which they are intended. You also have the additional guarentee that no libvirt client can ever see any key secrets or passphrases since it has been taken completely out of the loop. Key server | V MGMT server - libvirt client - libvirt daemon - qemu Storage of secrets in a separate keystore is more important for local libvirt deployments, where libvirt manages the primary, long-term, store of the secrets. Nope, I think that having a keystore for all scenarios is the desirable end goal. Passing secrets around in the XML should ideally never be done at all - we should aim to always have a keystore that can be used. Secrets in the XML would just be a fallback for a rarely used niche cases, or disaster recovery, or experimentation. As you say there are two initial approaches to persistence of secrets - Keep the keys in the domain XML files - Use a separate keystore For the separate keystore, there are probably 3 interesting targets to consider 1. A simple text (or pkcs11) file managed by libvirtd on the host This would be useful for the privileged libvirtd to use in ad-hoc, small scale deployments. Perhaps allowing it to be shared between a small number of hosts on NFS, or GFS etc 2. A desktop key agent (eg gnome-keyring) This would be useful for the unprivileged libvirtd instances that run in the context of the desktop login session. Users already have SSH, GPG, website keys stored here, so having keys for their VM disks is obviously desirable Another option here is to let the client store the secrets in gnome-keyring, and transfer them to libvirt only when starting a domain (especially when there are no persistent domains). That doesn't affect the design in any way, though. This is undesriable because it
Re: [libvirt] [PATCH 0/9] Add support for (qcow*) volume encryption
- Daniel P. Berrange berra...@redhat.com wrote: Not quite: the main case of a dumb client would be a large-scale virtualization management software that contains a primary store of encryption information, and gives each node access only to those keys that are currently necessary by the node to run its domains; the fact that each node has access to only a limited set of keys prevents an attacker that compromises a single node from reading disk images of all domains managed in the entire site, even if the disk image storage (e.g. unencrypted NFS) does not allow managing access by each node separately. Such a client must be able to transfer the actual secrets, not only identifiers, to libvirt. (The idea of a dumb client, that does not know the specifics of the format, is an additional feature on top, but one that implies that the client does send the actual secrets.) This implies a flow of secrets Key server --\ +- libvirt client - libvirt daemon - qemu MGMT server --/ This does not in fact guarentee that secrets for a particular node are only used on the node for which they are intended, because the key server cannot be sure of what libvirt daemons the libvirt client is connected to. A client in this case is the central, fully trusted, management system (e.g. oVirt), there is no need to protect against it. A more likely flow is MGMT client (no knowledge of secrets) | v MGMT server + key server (integrated or separate but cooperating) | v libvirt daemon | v qemu What I am suggesting is that libvirt daemon should communicate with the key server directly in all cases, and take the client out of the loop. The client should merely indicate whether it wants encryption or not, and never be able to directly access any key material itself. With a direct trust relationship between the key server and each libvirtd daemon, you do now have a guarentee that keys are only ever used on the node for which they are intended. You also have the additional guarentee that no libvirt client can ever see any key secrets or passphrases since it has been taken completely out of the loop. As far as I understand it, the whole point of virtual machine encryption is that the nodes are _not_ trusted, and different encryption keys protect data on different nodes. If all nodes are trusted, what additional functionality does volume encryption with per-volume keys provide? If the nodes are trusted to read only data from the domains they currently host, the nodes could just as well use an encrypted local hard drive to store all images, or share a single key to encrypt all images stored on a NFS/SAN. Key server | V MGMT server - libvirt client - libvirt daemon - qemu Storage of secrets in a separate keystore is more important for local libvirt deployments, where libvirt manages the primary, long-term, store of the secrets. Nope, I think that having a keystore for all scenarios is the desirable end goal. Passing secrets around in the XML should ideally never be done at all - we should aim to always have a keystore that can be used. Secrets in the XML would just be a fallback for a rarely used niche cases, or disaster recovery, or experimentation. That means that any deployment of more than one node with migration requires a separate server providing a shared keystore, even if there is only one client to manage the nodes. The N nodes x N management consoles case requires a centralized key store, but it's not necessary to impose it on the 1 management console case. 2. A desktop key agent (eg gnome-keyring) This would be useful for the unprivileged libvirtd instances that run in the context of the desktop login session. Users already have SSH, GPG, website keys stored here, so having keys for their VM disks is obviously desirable Another option here is to let the client store the secrets in gnome-keyring, and transfer them to libvirt only when starting a domain (especially when there are no persistent domains). That doesn't affect the design in any way, though. This is undesriable because it lets requires that any client which wishes to start the guest must have access to the secrets. We really need to be able to have separation of this, so that when we introduce fine grained access control, you can setup separate roles for users who can access / work with secrets, vs users who can start/define guests. 3. A off-node key management server This would be useful for a large scale data center / cluster cloud deployment. This is good to allow management scalability and better separation of responsiblities of adminstration. If no keystore is in use, then I clearly all keys
[libvirt] [PATCH 7/6] Only probe qemu for machine types when binary changes
By probing for qemu machine types, we increased the time of a
GetCapabilities call from 100us to a whopping 60ms.
This patch takes the approach of only probing for machine types
when the mtime of the emulator binary changed since the last time
the capabilities were generated.
This brings the time of the call back to what it was for the most
common case.
* src/capabilities.h: cache the emulator binary mtime
* src/qemu_conf.c: add qemudGetOldMachines() to copy the machine
types from the old caps struct if the mtime for the binary hasn't
changed
* src/qemu_conf.h, src/qemu_driver.c: pass the old caps pointer to
qemudCapsInit()
---
src/capabilities.h |1 +
src/qemu_conf.c| 97 ---
src/qemu_conf.h|2 +-
src/qemu_driver.c |4 +-
4 files changed, 95 insertions(+), 9 deletions(-)
diff --git a/src/capabilities.h b/src/capabilities.h
index aab084c..b958d95 100644
--- a/src/capabilities.h
+++ b/src/capabilities.h
@@ -49,6 +49,7 @@ struct _virCapsGuestDomainInfo {
char *loader;
int nmachines;
virCapsGuestMachinePtr *machines;
+time_t emulator_mtime; /* do @machines need refreshing? */
};
typedef struct _virCapsGuestDomain virCapsGuestDomain;
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index a3986df..a9d559e 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -457,7 +457,72 @@ rewait:
}
static int
+qemudGetOldMachines(const char *ostype,
+const char *arch,
+int wordsize,
+const char *emulator,
+time_t emulator_mtime,
+virCapsPtr old_caps,
+virCapsGuestMachinePtr **machines,
+int *nmachines)
+{
+int i;
+
+for (i = 0; i old_caps-nguests; i++) {
+virCapsGuestPtr guest = old_caps-guests[i];
+virCapsGuestDomainInfoPtr info = guest-arch.defaultInfo;
+virCapsGuestMachinePtr *list;
+
+if (!STREQ(ostype, guest-ostype) ||
+!STREQ(arch, guest-arch.name) ||
+wordsize != guest-arch.wordsize ||
+!STREQ(emulator, info-emulator))
+continue;
+
+if (emulator_mtime != info-emulator_mtime) {
+VIR_DEBUG(mtime on %s has changed, refreshing machine types,
+ info-emulator);
+return 0;
+}
+
+/* It sucks to have to dup these, when we're most likely going
+ * to free the old caps anyway - except if an error occurs, we'll
+ * stick with the old caps.
+ * Also, if we get OOM here, just let the caller try and probe
+ * the binary directly, which will probably fail too.
+ */
+if (VIR_ALLOC_N(list, info-nmachines) 0)
+return 0;
+
+for (i = 0; i info-nmachines; i++) {
+if (VIR_ALLOC(list[i]) 0) {
+virCapabilitiesFreeMachines(list, info-nmachines);
+return 0;
+}
+if (info-machines[i]-name
+!(list[i]-name = strdup(info-machines[i]-name))) {
+virCapabilitiesFreeMachines(list, info-nmachines);
+return 0;
+}
+if (info-machines[i]-canonical
+!(list[i]-canonical = strdup(info-machines[i]-canonical))) {
+virCapabilitiesFreeMachines(list, info-nmachines);
+return 0;
+}
+}
+
+*machines = list;
+*nmachines = info-nmachines;
+
+return 1;
+}
+
+return 0;
+}
+
+static int
qemudCapsInitGuest(virCapsPtr caps,
+ virCapsPtr old_caps,
const char *hostmachine,
const struct qemu_arch_info *info,
int hvm) {
@@ -467,8 +532,10 @@ qemudCapsInitGuest(virCapsPtr caps,
int haskqemu = 0;
const char *kvmbin = NULL;
const char *binary = NULL;
+time_t binary_mtime;
virCapsGuestMachinePtr *machines = NULL;
int nmachines = 0;
+struct stat st;
/* Check for existance of base emulator, or alternate base
* which can be used with magic cpu choice
@@ -507,6 +574,15 @@ qemudCapsInitGuest(virCapsPtr caps,
if (!binary)
return 0;
+if (stat(binary, st) == 0) {
+binary_mtime = st.st_mtime;
+} else {
+char ebuf[1024];
+VIR_WARN(_(Failed to stat %s, most peculiar : %s),
+ binary, virStrerror(errno, ebuf, sizeof(ebuf)));
+binary_mtime = 0;
+}
+
if (info-machine) {
virCapsGuestMachinePtr machine;
@@ -526,9 +602,16 @@ qemudCapsInitGuest(virCapsPtr caps,
machines[0] = machine;
nmachines = 1;
-
-} else if (qemudProbeMachineTypes(binary, machines, nmachines) 0)
-return -1;
+} else {
+int probe = 1;
+if (old_caps binary_mtime)
+probe = !qemudGetOldMachines(hvm ? hvm : xen, info-arch,
+
Re: [libvirt] [PATCH] document telnet serial console options
On Thu, Jul 23, 2009 at 09:44:24PM +0200, Guido Günther wrote: Hi, attached patch updates the console docs a bit. O.k. to apply? Cheers, -- Guido Looks fine to me, ACK :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | 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] OpenVZ : The restriction of domain name should be addressed
On Fri, Jul 24, 2009 at 05:47:10PM +0900, Yuji NISHIDA wrote: Hi, The current libvirt OpenVZ driver has a restriction that the domain names must match the OpenVZ container VEID I really want to have domain name as character, not integer. It could help me very much if any patch against this problem would be released. Is there anyone tackling this problem now?( or going to? ) Otherwise, any hint would help me. I don't think anybody has tried to handle this. The problem I think is that the mapping would have to be stored and if the hypervisor doesn't support this maintaining this data in a coherent fashion will be non-trivial. In any case the design for such a patch should be discussed here first and with the openvz maintainers to make sure the effort isn't wasted. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | 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] OpenVZ : The restriction of domain name should be addressed
Is there anyone tackling this problem now?( or going to? ) Otherwise, any hint would help me. I don't think anybody has tried to handle this. The problem I think is that the mapping would have to be stored and if the hypervisor doesn't support this maintaining this data in a coherent fashion will be non-trivial. In any case the design for such a patch should be discussed here first and with the openvz maintainers to make sure the effort isn't wasted. Openvz supports setting names for containers, see description on --name parameter in vzctl(8). But you (or libvirt) actually need to specify an unique container id anyway. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] OpenVZ : The restriction of domain name should be addressed
On Fri, Jul 24, 2009 at 06:23:21PM +0400, Anton Protopopov wrote: Is there anyone tackling this problem now?( or going to? ) Otherwise, any hint would help me. I don't think anybody has tried to handle this. The problem I think is that the mapping would have to be stored and if the hypervisor doesn't support this maintaining this data in a coherent fashion will be non-trivial. In any case the design for such a patch should be discussed here first and with the openvz maintainers to make sure the effort isn't wasted. Openvz supports setting names for containers, see description on --name parameter in vzctl(8). But you (or libvirt) actually need to specify an unique container id anyway. We should make use of this --name parameter then - I guess it didn't exist when we first wrote the driver. It is useful to users to have separate ID vs Name parameters - and in fact the current reusing of 'ID' for the name, causes a little confusion in virsh's lookup routines because it can't tell whether the parameter its given is a name or an ID, since they are identical. Regards, 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 0/1] Multipath pool support
On Thu, Jul 23, 2009 at 02:53:48PM -0400, Dave Allan wrote: Daniel P. Berrange wrote: It doesn't currently allow configuration of multipathing, so for now setting the multipath configuration will have to continue to be done as part of the host system build. Example XML to create the pool is: pool type=mpath namempath/name target path/dev/mapper/path /target /pool So this is in essence a 'singleton' pool, since there's only really one of them per host. There is also no quanity of storage associated with a mpath pool - it is simply dealing with volumes from other pools. This falls into the same conceptual bucket as things like DM-RAID, MD-RAID and even loopback device management. It is a singleton pool, in that there is only one dm instance per host. With regard to capacity, the dm devices have capacity, and their constituent devices could be members of other pools. Can you elaborate on what you see as the implications of those points? The storage pool vs storage volume concept was modelled around the idea that you have some storage source, and it is sub-divided into a number of volumes With multipath pool you have no storage source - the source is the SCSI/iSCSI pool which actually provides the underlying block provides which are the LUN paths. So by having a explicit storage pool for multipath, there's an implicit dependancy between 2 pools. If you refresh a SCSI pool, you must then refresh a multipath pool too. Or if you add a SCSI/iSCSI pool you must also refresh the multipath pool. There's also the issue of tracking the assoication between multipath volumes and the pools to ensure you don't remove a pool that's providing a multipath volume thats still in use. The question I've never been able to satisfactorily answer myself is whether these things(mpath,raid,loopback) should be living in the storage pool APIs, or in the host device APIs. I also wonder people determine the assoication between the volumes in the mpath pool, and the volumes for each corresponding path. eg, how do they determine that /dev/mapper/dm-4 multipath device is associated with devices from the SCSI storage pool 'xyz'. The storage volume APIs XML format don't really have a way to express this relationship. It's not difficult to query to find out what devices are parents of a given device, but what is the use case for finding out the pools of the parent devices? Say you have 3 SCSI NPIV pools configured, and a multipath pool. You want to remove one of the SCSI pools, and know that the multipath devices X, Y Z are in use. You need to determine which of the SCSI pools contains the underlying block devices for these multipath devices before you can safely remove that SCSI pool. The host device APIs have a much more limited set of operations (list, create, delete) but this may well be all that's needed for things like raid/mpath/loopback devices, and with its XML format being capability based we could add a multipath capability under which we list the constituent paths of each device. If we decide to implement creation and destruction of multipath devices, I would think the node device APIs would be the place to do it. If we intend to do creation/deletion of multipath devices in the node device APIs, then we esentially get listing of multipath devices in the node device APIs for free. So do we need a dedicated storage pool for multipath too ? I have a feeling that the DeviceKit impl of the node devive APIs (which is currently disabled by default, may already be reporting on all device mapper block devices - the HAL impl does not. Now, if my understanding is correct, then if multipath is active it should automatically create multipath devices for each unique LUN on a storage array. DM does SCSI queries to determine which block devices are paths to the same underlying LUN. That's basically correct, and the administrator can configure which devices have multipath devices created. Taking a simple iSCSI storage pool pool type='iscsi' namevirtimages/name source host name=iscsi.example.com/ device path=demo-target/ /source target path/dev/disk/by-path/path /target /pool this example would show you each individual block device, generating paths under /dev/disk/by-path. Now, we decide we want to make use of multipath for this particular pool. We should be able to just change the target path, to point to /dev/mpath, pool type='iscsi' namevirtimages/name source host name=iscsi.example.com/ device path=demo-target/ /source target path/dev/mpath/path /target /pool and have it give us back the unique multipath enabled LUNs, instead of each individual block device. The problem with this approach is that dm devices are not SCSI devices, so putting them in a SCSI pool seems wrong. iSCSI pools have always contained volumes which are iSCSI block devices, directory pools have always had volumes which are files.
Re: [libvirt] [PATCH] Power Hypervisor support
On Wed, Jul 22, 2009 at 04:01:47PM -0300, Eduardo Otubo wrote: Hello everyone, This should be the official patch for the libvrt-0.7.0 release. Here I'll comment all the features already implemented and the roadmap we have ahead: Features supported: * Connects to HMC/VIOS or IVM systems. * Life cycle commands (resume and shutdown). * dumpxml * 'list' and 'list --all' What is being implemented: * better and centralized control for UUID * definexml * CPU management commands Okidoc, I have pushed them to git, congrats ! Any comment are always welcome. [...] +static char * +phypExec(SSH_SESSION * session, char *cmd, int *exit_status, + virConnectPtr conn) [...] +char *lpar_name = +phypExec(ssh_session, cmd, (int *) exit_status, conn); obviously those (int *) exit_status had to be changed to exit_status I cleaned this up before the commit :-) I also had to clean a few things because the merge conflicted with the ESX one from yesterday but nothing important. However I have a serioud beef with the choice of libssh. That had been examined when this was started but I still think the issue should be revisited: - ESX driver now depend on libcurl which depends on the concurrent library libssh2 - libssh seems in its infancy, right now the version in Fedora development is 0.2, upstream is 0.3.1 radical change of naming - the phyp driver fails to build against 0.2 version, as they changed API signatures :-( , it compile agaisnt 0.3.1 but it's not generally available. - the -devel rpm doesn't even export a .pc file to easilly test against a given version in configure - rebuilding the src.rpm from upstream results in a shared lib being installed in libssh3, and the header files being in libssh-devel, when one consider there is also libssh2 needed for the build this is getting very very confusing - I have a very hard time promoting the use of a library which does things like typedef struct string_struct STRING; typedef struct buffer_struct BUFFER; and typedef uint32_t u32; typedef uint16_t u16; steeping onto the global naming space and being garanteed to be a pain in the long run (or completely break its published API to fix it) So right now I had to disable compilation of phys in the rpm because of those issues especially the API breakage leading to compilation failure if the wrong libssh-devel version was installed and the impossibility to test this easilly in the configure.in I somehow remember you might be okay to switch to libssh2 if really needed, and considering the uglyness of libssh current state I guess the option should be at least seriously considered. Anyway, this should not completely ruin this happy day, it's in, and issues will be fixed incrementally :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | 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] OpenVZ : The restriction of domain name should be addressed
2009/7/24 Daniel P. Berrange berra...@redhat.com On Fri, Jul 24, 2009 at 06:23:21PM +0400, Anton Protopopov wrote: Is there anyone tackling this problem now?( or going to? ) Otherwise, any hint would help me. I don't think anybody has tried to handle this. The problem I think is that the mapping would have to be stored and if the hypervisor doesn't support this maintaining this data in a coherent fashion will be non-trivial. In any case the design for such a patch should be discussed here first and with the openvz maintainers to make sure the effort isn't wasted. Openvz supports setting names for containers, see description on --name parameter in vzctl(8). But you (or libvirt) actually need to specify an unique container id anyway. We should make use of this --name parameter then - I guess it didn't exist when we first wrote the driver. It is useful to users to have separate ID vs Name parameters - and in fact the current reusing of 'ID' for the name, causes a little confusion in virsh's lookup routines because it can't tell whether the parameter its given is a name or an ID, since they are identical. There is still a question of how to specify both a name and CTID in XML description. By default, CTID can be obtained as openvzGimmeFirstUnusedCTID(), but actually I think that there exists a number of persons interested in giving CTIDs manually. Regards, 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/http://search.cpan.org/%7Edanberr/:| |: 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] [PATCH] test: Implement BlockStats and InterfaceStats
We fake stats values based on the current time, similar to how it's done
for cpu time.
---
src/test.c | 116 ++-
1 files changed, 114 insertions(+), 2 deletions(-)
diff --git a/src/test.c b/src/test.c
index f02b58b..6db3825 100644
--- a/src/test.c
+++ b/src/test.c
@@ -2093,6 +2093,118 @@ cleanup:
return ret;
}
+static int testDomainBlockStats(virDomainPtr domain,
+const char *path,
+struct _virDomainBlockStats *stats)
+{
+testConnPtr privconn = domain-conn-privateData;
+virDomainObjPtr privdom;
+struct timeval tv;
+unsigned long long statbase;
+int i, found = 0, ret = -1;
+
+testDriverLock(privconn);
+privdom = virDomainFindByName(privconn-domains,
+ domain-name);
+testDriverUnlock(privconn);
+
+if (privdom == NULL) {
+testError(domain-conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
+goto error;
+}
+
+for (i = 0 ; i privdom-def-ndisks ; i++) {
+if (STREQ(path, privdom-def-disks[i]-dst)) {
+found = 1;
+break;
+}
+}
+
+if (!found) {
+testError(domain-conn, VIR_ERR_INVALID_ARG,
+ _(invalid path: %s), path);
+goto error;
+}
+
+if (gettimeofday(tv, NULL) 0) {
+virReportSystemError(domain-conn, errno,
+ %s, _(getting time of day));
+goto error;
+}
+
+/* No significance to these numbers, just enough to mix it up*/
+statbase = (tv.tv_sec * 1000UL * 1000UL) + tv.tv_usec;
+stats-rd_req = statbase / 10;
+stats-rd_bytes = statbase / 20;
+stats-wr_req = statbase / 30;
+stats-wr_bytes = statbase / 40;
+stats-errs = tv.tv_sec / 2;
+
+ret = 0;
+error:
+if (privdom)
+virDomainObjUnlock(privdom);
+return ret;
+}
+
+static int testDomainInterfaceStats(virDomainPtr domain,
+const char *path,
+struct _virDomainInterfaceStats *stats)
+{
+testConnPtr privconn = domain-conn-privateData;
+virDomainObjPtr privdom;
+struct timeval tv;
+unsigned long long statbase;
+int i, found = 0, ret = -1;
+
+testDriverLock(privconn);
+privdom = virDomainFindByName(privconn-domains,
+ domain-name);
+testDriverUnlock(privconn);
+
+if (privdom == NULL) {
+testError(domain-conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
+goto error;
+}
+
+for (i = 0 ; i privdom-def-nnets ; i++) {
+if (privdom-def-nets[i]-ifname
+STREQ (privdom-def-nets[i]-ifname, path)) {
+ret = 0;
+break;
+}
+}
+
+if (!found) {
+testError(domain-conn, VIR_ERR_INVALID_ARG,
+ _(invalid path, '%s' is not a known interface), path);
+goto error;
+}
+
+if (gettimeofday(tv, NULL) 0) {
+virReportSystemError(domain-conn, errno,
+ %s, _(getting time of day));
+goto error;
+}
+
+/* No significance to these numbers, just enough to mix it up*/
+statbase = (tv.tv_sec * 1000UL * 1000UL) + tv.tv_usec;
+stats-rx_bytes = statbase / 10;
+stats-rx_packets = statbase / 100;
+stats-rx_errs = tv.tv_sec / 1;
+stats-rx_drop = tv.tv_sec / 2;
+stats-tx_bytes = statbase / 20;
+stats-tx_packets = statbase / 110;
+stats-tx_errs = tv.tv_sec / 3;
+stats-tx_drop = tv.tv_sec / 4;
+
+ret = 0;
+error:
+if (privdom)
+virDomainObjUnlock(privdom);
+return ret;
+}
+
static virDrvOpenStatus testOpenNetwork(virConnectPtr conn,
virConnectAuthPtr auth
ATTRIBUTE_UNUSED,
int flags ATTRIBUTE_UNUSED) {
@@ -4117,8 +4229,8 @@ static virDriver testDriver = {
NULL, /* domainMigratePrepare */
NULL, /* domainMigratePerform */
NULL, /* domainMigrateFinish */
-NULL, /* domainBlockStats */
-NULL, /* domainInterfaceStats */
+testDomainBlockStats, /* domainBlockStats */
+testDomainInterfaceStats, /* domainInterfaceStats */
NULL, /* domainBlockPeek */
NULL, /* domainMemoryPeek */
testNodeGetCellsFreeMemory, /* nodeGetCellsFreeMemory */
--
1.6.0.6
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] python: Raise exceptions if virDomain*Stats fail.
The generator couldn't tell that the stats return values were pointers.
Stick a white list in the function which tries to make this distinction.
---
python/generator.py |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/python/generator.py b/python/generator.py
index 9528839..feff7a3 100755
--- a/python/generator.py
+++ b/python/generator.py
@@ -683,7 +683,10 @@ functions_list_exception_test = {
functions_list_default_test = %s is None
def is_list_type (name):
-return name[-1:] == *
+whitelist = [ virDomainBlockStats,
+ virDomainInterfaceStats ]
+
+return name[-1:] == * or name in whitelist
def nameFixup(name, classe, type, file):
# avoid a desastrous clash
--
1.6.0.6
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [PATCH 7/6] Only probe qemu for machine types when binary changes
Mark McLoughlin wrote: By probing for qemu machine types, we increased the time of a GetCapabilities call from 100us to a whopping 60ms. This patch takes the approach of only probing for machine types when the mtime of the emulator binary changed since the last time the capabilities were generated. Good idea! This brings the time of the call back to what it was for the most common case. * src/capabilities.h: cache the emulator binary mtime * src/qemu_conf.c: add qemudGetOldMachines() to copy the machine types from the old caps struct if the mtime for the binary hasn't changed * src/qemu_conf.h, src/qemu_driver.c: pass the old caps pointer to qemudCapsInit() --- src/capabilities.h |1 + src/qemu_conf.c| 97 --- src/qemu_conf.h|2 +- src/qemu_driver.c |4 +- 4 files changed, 95 insertions(+), 9 deletions(-) ... ACK, patch looks good to me. - Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [PATCH] test: Implement BlockStats and InterfaceStats
Cole Robinson wrote:
We fake stats values based on the current time, similar to how it's done
for cpu time.
---
src/test.c | 116 ++-
1 files changed, 114 insertions(+), 2 deletions(-)
Of course, I do all this, then don't even test that InterfaceStats actually
works. The following additive patch is required:
@@ -2170,7 +2170,7 @@ static int testDomainInterfaceStats(virDomainPtr domain,
for (i = 0 ; i privdom-def-nnets ; i++) {
if (privdom-def-nets[i]-ifname
STREQ (privdom-def-nets[i]-ifname, path)) {
-ret = 0;
+found = 1;
break;
}
}
Thanks,
Cole
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] python: Raise exceptions if virDomain*Stats fail.
On Fri, Jul 24, 2009 at 11:05:27AM -0400, Cole Robinson wrote: The generator couldn't tell that the stats return values were pointers. Stick a white list in the function which tries to make this distinction. Ah, ACK :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | 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] [PATCH] Don't allow NULL paths for BlockStats and InterfaceStats
On Fri, Jul 24, 2009 at 11:05:28AM -0400, Cole Robinson wrote: Do the check in libvirt.c, to save drivers from the burden. This changes behavior slightly in the qemu driver: we no longer explictly error if passed an empty string. An error will still be thrown when the device lookup fails. ACK, I would just add (path[0] = 0) as one of the parameter failure in libvirt.c directly Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | 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] [PATCH] test: Generate net interface names when assigning XML.
On Fri, Jul 24, 2009 at 11:05:29AM -0400, Cole Robinson wrote: We need interface names to implement InterfaceStats. --- src/test.c | 76 +-- 1 files changed, 68 insertions(+), 8 deletions(-) Looks fine but I'm not completely sure why we need this :-) ACK Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | 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] [PATCH] test: Implement BlockStats and InterfaceStats
On Fri, Jul 24, 2009 at 11:05:30AM -0400, Cole Robinson wrote:
We fake stats values based on the current time, similar to how it's done
for cpu time.
+if (gettimeofday(tv, NULL) 0) {
+virReportSystemError(domain-conn, errno,
+ %s, _(getting time of day));
+goto error;
+}
can gettimeofday fail if the args are correct ? But that's fine :-)
With the second patch that looks fine.
ACK
daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | 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] [PATCH] test: Generate net interface names when assigning XML.
Daniel Veillard wrote: On Fri, Jul 24, 2009 at 11:05:29AM -0400, Cole Robinson wrote: We need interface names to implement InterfaceStats. --- src/test.c | 76 +-- 1 files changed, 68 insertions(+), 8 deletions(-) Looks fine but I'm not completely sure why we need this :-) ACK Daniel I've been reworking some of the graph UI in virt-manager, and it's very handy to use the test driver, as opposed to several real guests with disk and network activity. - Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/9] Add support for (qcow*) volume encryption
Replying to my own message... On Fri, Jul 24, 2009 at 02:04:33PM +0100, Daniel P. Berrange wrote: We also have to bear in mind how the MGMT server communicates with the libvirt daemon. One likely option is using a messaging service, which offers authenticity but not secrecy. ie, libvirt receiving a request off the message bus can be sure the request came from the mgmtm server, but cannot be sure it wasn't seen by other users during transport. Thus by including secrets in the XML, you could be exposing them to the message bus adminstrator. [snip] - A node can only see secrets for VMs it is configured to run - MGMT server does not need to ever see the secrets itself. It merely controls access for which nodes can see them, and can request generation of new secrets - Messages between the MGMT server libvirtd do not need to be encrypted, since they don't include secrets - Other users who authenticate to libvirt on a node cannot move a VM to an unauthorized node, since it can't see secrets - VM save memory images (which include the fully XML) do not ever expose the secrets. So VM save image cannot be restored on an unauthorized node. [snip] one. I think it is very important that all these deployment scenarios can be supported without including the secrets in the XML config, since there are fr too many ways in which the XML config itself may be exposed to undesirable places. Now that I look back on this, the implications of storing any passphrases or secrets or keys in the XML are just horrific. There are soo many places in which this data would leak out to untrusted sources. Just look at virt-manager, virt-install, virsh, libvirtd, and indeed libvirt.so itself. All of these tools have logging / debugging options which cause the full XML docs of guest domains and storage volumes to be sent to log files, or syslog. When debuging issues reported with bugzilla we pretty much require that people provide logs from libvirt.so and apps involved. This presents such an unacceptably high risk of compromising secrets, that IMHO we not add any support in libvirt for storing secrets in the XML whatsoever. We should go straight for one of 2 options - API for clients to directly create/delete/list/generate And/or - libvirtd backend that talks to a key sever to indirectly fetch secrets And in the XML docs always reference keys based on a unique identifier of some form. Regards, 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 1/1] Support for Callbacks and VirtualBox Version 3.
On Fri, Jul 17, 2009 at 03:39:07PM +0200, Pritesh Kothari wrote: the patch with above changes is attached below: Okidoc, applied and commited, no problem ! thanks, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | 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] test driver and virtOpenAuth()
I am trying to test a call into virConnectOpenAuth. How can I configure the test driver to accept auth calls on test+tcp://localhost/default Thanks! -- bk -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] test driver and virtOpenAuth()
On Fri, Jul 24, 2009 at 01:56:24PM -0400, Bryan Kearney wrote: I am trying to test a call into virConnectOpenAuth. How can I configure the test driver to accept auth calls on test+tcp://localhost/default Start libvirtd as root, with SASL enabled. It is not the kind of thing you want todo from a test suite though. 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] test driver and virtOpenAuth()
Daniel P. Berrange wrote: On Fri, Jul 24, 2009 at 01:56:24PM -0400, Bryan Kearney wrote: I am trying to test a call into virConnectOpenAuth. How can I configure the test driver to accept auth calls on test+tcp://localhost/default Start libvirtd as root, with SASL enabled. It is not the kind of thing you want todo from a test suite though. Daniel Thanks. I am trying test script which DV wrote. So, this is more of a one-off. to enable sasl, I edited the following in my libvirtd.conf. Is this correct: listen_tcp = 1 tcp_port = 16509 listen_addr = 192.168.0.1 auth_unix_ro = sasl auth_unix_rw = sasl auth_tcp = sasl auth_tls = sasl Is that all I need to do? -- bk -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Power Hypervisor support
On Thu, 2009-07-23 at 21:52 +0100, Daniel P. Berrange wrote: On Wed, Jul 22, 2009 at 04:01:47PM -0300, Eduardo Otubo wrote: Hello everyone, This should be the official patch for the libvrt-0.7.0 release. Here I'll comment all the features already implemented and the roadmap we have ahead: Features supported: * Connects to HMC/VIOS or IVM systems. * Life cycle commands (resume and shutdown). * dumpxml * 'list' and 'list --all' What is being implemented: * better and centralized control for UUID * definexml * CPU management commands Any comment are always welcome. I think it is worth merging this patch now. While there's still more changes I'd like to see in the code, it'll be easier to address them once merged - keeping it out of tree for longer is counterproductive. Yes, I agree with that. BTW, if you could provide a short introduction outlining any important points for the Phyp driver that'd be great. Driver docs under under the directory docs/drvX.html.in - the .html is generated from the .html.in file. Just create a new docs/drvphyp.html.in, and list it in the sitemap.html.in file Sure, I'll write some lines about how it works and so on. It should be for this release or in some future patch would be ok also? []'s -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems Technology Group Mobile: +55 19 8135 0885 ot...@linux.vnet.ibm.com -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Power Hypervisor support
On Fri, 2009-07-24 at 16:42 +0200, Daniel Veillard wrote: On Wed, Jul 22, 2009 at 04:01:47PM -0300, Eduardo Otubo wrote: Hello everyone, This should be the official patch for the libvrt-0.7.0 release. Here I'll comment all the features already implemented and the roadmap we have ahead: Features supported: * Connects to HMC/VIOS or IVM systems. * Life cycle commands (resume and shutdown). * dumpxml * 'list' and 'list --all' What is being implemented: * better and centralized control for UUID * definexml * CPU management commands Okidoc, I have pushed them to git, congrats ! Thank you very much! :) Any comment are always welcome. [...] +static char * +phypExec(SSH_SESSION * session, char *cmd, int *exit_status, + virConnectPtr conn) [...] +char *lpar_name = +phypExec(ssh_session, cmd, (int *) exit_status, conn); obviously those (int *) exit_status had to be changed to exit_status I cleaned this up before the commit :-) I also had to clean a few things because the merge conflicted with the ESX one from yesterday but nothing important. However I have a serioud beef with the choice of libssh. That had been examined when this was started but I still think the issue should be revisited: - ESX driver now depend on libcurl which depends on the concurrent library libssh2 - libssh seems in its infancy, right now the version in Fedora development is 0.2, upstream is 0.3.1 radical change of naming - the phyp driver fails to build against 0.2 version, as they changed API signatures :-( , it compile agaisnt 0.3.1 but it's not generally available. - the -devel rpm doesn't even export a .pc file to easilly test against a given version in configure - rebuilding the src.rpm from upstream results in a shared lib being installed in libssh3, and the header files being in libssh-devel, when one consider there is also libssh2 needed for the build this is getting very very confusing - I have a very hard time promoting the use of a library which does things like typedef struct string_struct STRING; typedef struct buffer_struct BUFFER; and typedef uint32_t u32; typedef uint16_t u16; steeping onto the global naming space and being garanteed to be a pain in the long run (or completely break its published API to fix it) So right now I had to disable compilation of phys in the rpm because of those issues especially the API breakage leading to compilation failure if the wrong libssh-devel version was installed and the impossibility to test this easilly in the configure.in I somehow remember you might be okay to switch to libssh2 if really needed, and considering the uglyness of libssh current state I guess the option should be at least seriously considered. Daniel, As we talked in the IRC, I'll start working on the migration to libssh2. I'll post my feedbacks as soon as I have some compilable code to show :) []'s -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems Technology Group Mobile: +55 19 8135 0885 ot...@linux.vnet.ibm.com -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
