[Libvir] Storage manager initial requirements and thoughts
by Hugh Brock
Hi all.
At the Red Hat virtualization team meeting last week we spent some time
talking about the problem of remote storage management, which is a
requirement for at the very least creating remote guests. Remote storage
management also delivers a lot of benefits for managing guest storage,
provisioning, and a host of other issues.
Note that we don't (I think) believe that storage management should be
part of libvirt. However we might want to be able to grab storage
information with libvirt when creating a guest, for example.
Here's the tentative requirements we came up with, along with several
questions that came up.
We have two important use cases for remote storage management:
--Create a new guest against an existing physical device
--Create a new guest against a file on an existing physical device
(SELinux context must match up on both)
Requirements:
2 key requirements: enumerate devices, create files
* Enumerate devices (unallocated disks)
* storage pool
* Unallocated space
* Allocated volumes
-- free
-- in use
* Read only / Read-write
* Host availability
* Volume
-- Global unique name
-- Local device name
-- Usage
-- Mounted locally
-- Assigned to guest
read only
shared
exclusive
-- Inactive guest
* Create a backing store for a guest
* need to know what storage is available
* Can be plain file
* Can be a physical partition (local scsi/IDE, SAN)
* Can be a logical volume
* Can be network - iscsi/nbd
Cases:
Physical device
--> create partitions
Volume group
--> create logical volumes
Directory
--> create files
Todos:
Investigate gparted, one of the partition management tools we already
have (apis? remote accessibility?) (I believe Jim Meyering volunteered
to take a look at this?)
Identify what other scenarios we need to address.
Please comment; I'm hoping we can get these into a more definite form
sooner rather than later.
--
Red Hat Virtualization Group http://redhat.com/virtualization
Hugh Brock | virt-manager http://virt-manager.org
hbrock(a)redhat.com | virtualization library http://libvirt.org
16 years, 11 months
[Libvir] [PATCH] Add a default network
by Mark McLoughlin
Hey,
So, we want to install a default network which guests can connect to.
This can be seen as e.g. a replacement for xenbr0 as the default bridge
for xen guests.
A few things concern me about the patch, see below for my thinking.
However, I'm happy to punt on all of these issues for now and go ahead
with the patch.
1) Ordering - we want the default network to have a predictable bridge
name, so instead of relying on it being the first network and
ending up auto-allocated vnet0, we use virbr0.
The alternative is to actually have an ordering scheme, e.g.
#define LIBVIRT_AUTOSTART_PRIORITY_DISABLE -1
#define LIBVIRT_AUTOSTART_PRIORITY_FIRST 0
#define LIBVIRT_AUTOSTART_PRIORITY_LAST 99
#define LIBVIRT_AUTOSTART_PRIORITY_DEFAULT 50
int virNetworkSetAutostart(virDomainPtr domain,
int priority);
autostart/00-default.xml -> ../default.xml
autostart/99-MyNetwork.xml -> ../MyNetwork.xml
Maybe that's useful, but probably moreso for guests than networks.
The "virbr0" solution is fine, IMHO.
2) IP address choice - I've randomly chosen 192.168.122.1/24 as the
IP address for the network, and this could happen to clash with
an existing network. Since we masquerade outgoing traffic, I think
the only problem this would cause in practice would be where the
host machine is already on a 192.168.122/24 subnet and it could
find itself connecting to a guest rather than another machine on
the physical subnet.
It's a default configuration choice which admins can change, and I
don't see it causing huge problems in practice, so I'm not overly
concerned.
If it did turn out to be a problem, I'd probably add something
like:
<ip type="auto" />
But I'm not anxious to go down that route right now.
3) UUID generation - there's no UUID specified, so the default
network will have a different UUID across reboots.
We could trivially save the UUID at first boot, but we'd really
need to put it in /var then.
IMHO, it's something we can fix later if it turns out to be
important.
Cheers,
Mark.
17 years, 2 months
[Libvir] [PATCH] export virConf* symbols (second version)
by Richard W.M. Jones
Second version of that patch.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
17 years, 2 months
[Libvir] Remote patch, 2007-02-28
by Richard W.M. Jones
http://www.annexia.org/tmp/libvirt-tls-20070228.patch
Not an enormous amount of difference between this and the patch from two
days ago. This patch correctly logs/audits new connections and fixes a
whole collection of different bugs which used to happen when the server
rejected a client connection.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
17 years, 2 months
[Libvir] Patch: Fix documentation and code of virGetDomain function
by Richard W.M. Jones
It turns out that you _can't_ pass name=NULL to virGetDomain, despite
what the docs say.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
17 years, 2 months
[Libvir] [PATCH] patch for virsh domname <uuid> command error
by Tatsuro Enokura
Hi,
Virsh domname <uuid> command for shut-off domain fails on xen-3.0.4.
I think that xm_internal.c shoud be modified.
But, it seems that xm_internal's structure isn't for xen-3.0.4,
and shut-off domain's information is got from xend.
I make a patch for xend_internal.c
The attached patch resolve this issue in the following way:
1) If the domain's name can't be pulled out from
the running domains list by uuid, request xend by
"/xend/domains/<uuid>".
2) If the domain's data can be teken from xend, pull out
the domain's name.
Signed-off-by: Tatsuro Enokura <fj7716hz(a)aa.jp.fujitsu.com>
Thanks,
Tatsuro Enokura.
Index: src/xend_internal.c (libvirt-0.2.0)
===================================================================
--- xend_internal.c 2007-02-15 01:16:16.000000000 +0900
+++ xend_internal.c.new 2007-02-23 21:13:22.000000000 +0900
@@ -2759,6 +2759,8 @@ xenDaemonLookupByUUID(virConnectPtr conn
char **tmp;
unsigned char ident[VIR_UUID_BUFLEN];
int id = -1;
+ struct sexpr *root = NULL;
+ char *domname = NULL;
names = xenDaemonListDomainsOld(conn);
tmp = names;
@@ -2779,6 +2781,26 @@ xenDaemonLookupByUUID(virConnectPtr conn
}
free(names);
+ if (name == NULL) {
+ char uuidstr[VIR_UUID_STRING_BUFLEN];
+ memset(uuidstr, '\0', VIR_UUID_STRING_BUFLEN);
+
+ snprintf(uuidstr, VIR_UUID_STRING_BUFLEN,
+
"%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x",
+ uuid[0], uuid[1], uuid[2], uuid[3],
+ uuid[4], uuid[5], uuid[6], uuid[7],
+ uuid[8], uuid[9], uuid[10], uuid[11],
+ uuid[12], uuid[13], uuid[14], uuid[15]);
+ root = sexpr_get(conn, "/xend/domain/%s?detail=1", uuidstr);
+ if (root == NULL)
+ goto error;
+ domname = (char*)sexpr_node(root, "domain/name");
+ if (domname == NULL)
+ goto error;
+ name = strdup(domname);
+ id = -1;
+ }
+
if (name == NULL)
goto error;
@@ -2793,6 +2815,8 @@ xenDaemonLookupByUUID(virConnectPtr conn
return (ret);
error:
+ if (root != NULL)
+ sexpr_free(root);
if (name != NULL)
free(name);
return (NULL);
===================================================================
17 years, 2 months
[Libvir] [PATCH]Report the error from xend for Domain-0
by Kazuki Mizushima
Hi,
When I test virsh subcommands, dump save, for Domain-0,
It says following normal messages, but the processing is not done.
#virsh dump 0 a
Domain 0 dumpd to a
#echo $?
0
#virsh save 0 a
Domain 0 saved to a
#echo $?
0
I made a patch which reports the error from xend like this.
#virsh dump 0 a
libvir: Xen Daemon error : POST operation failed: (xend.err 'Cannot save privileged domain 0')
libvir: error : library call virDomainSave failed, possibly not supported
error: Failed to save domain 0 to a
# echo $?
1
#virsh dump 0 a
libvir: Xen Daemon error : POST operation failed: (xend.err 'Cannot dump core for privileged domain 0')
libvir: error : library call virDomainCoreDump failed, possibly not supported
error: Failed to core dump domain 0 to a
# echo $?
1
Signed-off-by: Kazuki Mizushima <mizushima.kazuk(a)jp.fujitsu.com>
Thanks,
Kazuki Mizushima
Index: xend_internal.c (libvirt-0.2.0)
----------------------------------------------------------------------
--- ../../libvirt-0.2.0/src/xend_internal.c 2007-02-15 01:16:16.000000000 +0900
+++ xend_internal.c 2007-02-27 22:45:05.000000000 +0900
@@ -507,7 +507,10 @@ xend_post(virConnectPtr xend, const char
if ((ret < 0) || (ret >= 300)) {
virXendError(xend, VIR_ERR_POST_FAILED, content);
- } else if ((ret = 202) && (strstr(content, "failed") != NULL)) {
+ } else if ((ret == 202) && (strstr(content, "failed") != NULL)) {
+ virXendError(xend, VIR_ERR_POST_FAILED, content);
+ ret = -1;
+ } else if ((ret == 202) && (strcasestr(content, "cannot") != NULL)) {
virXendError(xend, VIR_ERR_POST_FAILED, content);
ret = -1;
}
----------------------------------------------------------------------
17 years, 2 months
[Libvir] Patch: driver->open functions return declined or error status
by Richard W.M. Jones
I want to change the driver->open function so that as well as declining
a name (returning -1 as now), it may also indicate that it accepts the
name, but there is an error opening the name (-2). virConnectOpen fails
in this second case, rather than going on and trying the next driver in
sequence.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
17 years, 2 months
[Libvir] ABI compatibility question: static strings returned from some functions
by Richard W.M. Jones
We have some functions such as virConnectGetType which are defined to
return statically allocated strings:
/**
* virConnectGetType:
* @conn: pointer to the hypervisor connection
*
* Get the name of the Hypervisor software used.
*
* Returns NULL in case of error, a static zero terminated string
otherwise.
*/
const char *
virConnectGetType(virConnectPtr conn)
[...]
This is all well and good in the typical local case, but when working
over a remote connection the string we return is allocated and requires
freeing at some point. Unfortunately I don't see a good thing to do in
this case except to change the semantics of virConnectGetType, which
arguably breaks ABI compatibility.
Suggestions from anyone?
Rich.
garbage.collection++
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
17 years, 2 months
[Libvir] Patch: Driver private data
by Richard W.M. Jones
This patch is more aspirational than currently useful. Only the remote
patch would use driver->private, but I think others should be changed to
do so too.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
17 years, 2 months