[libvirt] [PATCH] introducing <source> <name> (for logical storage pools)
by David Lively
Hi Folks -
This small patch is a proposed prerequisite for the storage pool
discovery patch I submitted last week.
Daniel B proposed having storage pool discovery return a bunch of XML
storage <source> elements, rather than full <pool> elements (which
contain "target-dependent" details like the local pool name and device
or mount path -- things which don't need to be decided unless/until the
pool is defined).
I like his suggestion a lot, and I think it addresses the final
API-definition problem keeping storage pool discovery out of libvirt.
But ... it doesn't quite work for logical storage pools because those
are created from the <pool> <name> element (which is the same as the
volume group name).
This patch introduces a new <source> element <name>, which is
distinct
from the pool name. <name> is used only by the logical storage
backend, and represents the volume group name. For convenience and
back-compatibility, <source> <name> defaults to the pool name if not
specified when the pool is defined, and <pool> <name> defaults to the
source name if not specified. There is no requirement that pool and
source name be the same, though.
While admittedly it seems a little weird, it does allow more
flexibility (pool name not tied to vol group name), and allows <source>
to fully specify a logical pool source, as it does for the other pool
types[*]. Defaulting the source name from the pool name means all
existing pool XML definitions continue to work. Defaulting the pool
name from the source name is simply a matter of convenience (but perhaps
a step too far?)
If this is accepted, logical pool discovery can then return a bunch of
sources like:
<source><name>VolGroup00</name></source>
<source><name>VolGroup01</name></source>
Please note I'll be on vacation next week (Aug 11-15), so I may not be
responding until the following week.
Thanks,
Dave
[*] Well ... almost. Note that directory pools have a similar issue --
the "source" of the pool is given by the <target> <path> -- there's no
<source>. I suppose implementing directory pool discovery (for the sake
of completeness) means addressing this as well, maybe via some similar
mechanism ...
16 years, 3 months
[libvirt] libvir: Xen error
by mantra UNIX
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.
--
Regards,
mantra - Instrument of Thought
16 years, 3 months
[libvirt] Storage LVM volume mounted with filesystem
by Ricardo Tiago
Hi,
I'm quite new to libvirt, and i have a question regarding the storage
capabilities in libvirt. I have reading the documentation but i
couldn't figure it out if its possible to specify in the LVM volume
xml description that i want the new volume to be mounted with a
filesystem.
I'm using libvirt-0.4.4
My current volume xml is:
<volume type="fs">
<name>sl5-root</name>
<allocation>0</allocation>
<capacity>5000000000</capacity>
<target>
<path>/tmp/sl5</path>
<permissions>
<owner>0744</owner>
<group>0744</group>
<mode>0744</mode>
<label>virt_image_t</label>
</permissions>
</target>
</volume>
/tmp/sl5 is a ext3 filesystem that i would like to see mounted in the
newly create lvm volume.
My pool xml:
<pool type="logical">
<name>vg1</name>
<target>
<path>/dev/vg1</path>
</target>
</pool>
Thanks
Ricardo
16 years, 3 months
[libvirt] [PATCH] Set correct device type when parsing input devices
by Cole Robinson
In virDomainDeviceDefParse, parsing an input device
was actually setting it's type as DEVICE_DISK. The
attached patch fixes this.
Thanks,
Cole
commit 75150ac2536c427f74875fc563abf2fc06595dda
Author: Cole Robinson <crobinso(a)dhcp-100-19-219.bos.redhat.com>
Date: Thu Aug 21 13:27:38 2008 -0400
Fix setting input device type in virDomainDeviceDefParse.
diff --git a/src/domain_conf.c b/src/domain_conf.c
index d482e68..6b23474 100644
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -1656,7 +1656,7 @@ virDomainDeviceDefPtr virDomainDeviceDefParse(virConnectPtr conn,
if (!(dev->data.net = virDomainNetDefParseXML(conn, node)))
goto error;
} else if (xmlStrEqual(node->name, BAD_CAST "input")) {
- dev->type = VIR_DOMAIN_DEVICE_DISK;
+ dev->type = VIR_DOMAIN_DEVICE_INPUT;
if (!(dev->data.input = virDomainInputDefParseXML(conn, def->os.type, node)))
goto error;
} else if (xmlStrEqual(node->name, BAD_CAST "sound")) {
16 years, 3 months
[libvirt] [PATCH] Don't list capabilities entries if emulators can't be accessed
by Cole Robinson
The patch below fixes capabilities xml generation for
the qemu driver if the emulators aren't found in the
hardcoded paths. Current behavior will add a <guest>
entry for the emulator even if it does not exist, patch
fixes this to check that we actually have access.
This brings up another issue, that hardcoded paths
aren't exactly distro friendly. I'm not really familiar
with what options we have to allow specifying these
at build time (or something else). Anyone have an
idea?
Thanks,
Cole
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index dc9e42a..0328cc1 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -230,6 +230,10 @@ qemudCapsInitGuest(virCapsPtr caps,
virCapsGuestPtr guest;
int i;
+ /* Check for existance of base emulator */
+ if (access(info->binary, X_OK) == -1)
+ return 0;
+
if ((guest = virCapabilitiesAddGuest(caps,
hvm ? "hvm" : "xen",
info->arch,
@@ -241,9 +245,7 @@ qemudCapsInitGuest(virCapsPtr caps,
return -1;
if (hvm) {
- /* Check for existance of base emulator */
- if (access(info->binary, X_OK) == 0 &&
- virCapabilitiesAddGuestDomain(guest,
+ if (virCapabilitiesAddGuestDomain(guest,
"qemu",
NULL,
NULL,
@@ -263,6 +265,7 @@ qemudCapsInitGuest(virCapsPtr caps,
return -1;
if (access("/dev/kvm", F_OK) == 0 &&
+ access("/usr/bin/qemu-kvm", X_OK) == 0 &&
virCapabilitiesAddGuestDomain(guest,
"kvm",
"/usr/bin/qemu-kvm",
16 years, 3 months
[libvirt] Unable to find node's mem and cpu api
by jovialGuy _
hey,
I am unable to find the api in java and perl binding to find the host node's
current memory and cpu information. Any body has any idea where I can find
the information?
- Jovial
16 years, 4 months
[libvirt] Confirm libvirt supported distro?
by atif bajwa
Hi!
I have a list of Linux distributions with Xen support. Please confirm
libvirt (remote access, >= version 0.3.0 ) support.
1. Solaris SPARC 81/9/10
2. Solaris x64/x86 9/10
3. Red Hat RHEL AS/ES/WS 3/4/5
4. Novell SUSE & SLES 8/9/10
Regards,
Atif
16 years, 4 months
