[libvirt] Uknown OS typehvm
by Fred Leeflang
Hello,
I've had an older version of libvirtd/qemu running on Debian Lenny and had
defined 4 virtual servers.
I have the kvm and kvm_intel modules loaded (also compiled from source). I
copied over my 4 config
files from /etc/libvirt/qemu to /usr/local/etc/libvirt/qemu
Now when I start up libvirtd -v:
omega:~# libvirtd -v
20:17:38.877: warning : qemudStartup:566 : Unable to create cgroup for
driver: No such device or address
libvir: Domain Config error : unknown OS type hvm
libvir: Domain Config error : unknown OS type hvm
libvir: Domain Config error : unknown OS type hvm
libvir: Domain Config error : unknown OS type hvm
I'm trying to make sense out of the config files at this point but not very
successful at it. I googled around
a bit to see if others had this error message but most of the ones I found
relate to not having the kernel
modules loaded, which is visible in the 'virsh capabilities' output. Mine
shows:
fredl@omega:~$ which virsh
/usr/local/bin/virsh
fredl@omega:~$ virsh capabilities
<capabilities>
<host>
<cpu>
<arch>x86_64</arch>
</cpu>
<migration_features>
<live/>
<uri_transports>
<uri_transport>tcp</uri_transport>
</uri_transports>
</migration_features>
</host>
</capabilities>
This seems odd, this is from my /proc/cpuinfo:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp
lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr
pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
So the processor is capable of it, however:
fredl@omega:~$ virsh version
Compiled against library: libvir 0.7.1
Using library: libvir 0.7.1
Using API: QEMU 0.7.1
*error: failed to get the hypervisor version
error: Unknown failure
*
I'm guessing that's the problem and I realized that in the Debian package
the qemu binary is named 'kvm' (may be a symlink) while mine's in
-rwxr-xr-x 1 root staff 2286848 2009-09-26 19:31
/usr/local/bin/qemu-system-x86_64
So how does libvirtd try to find out the hypervisor version? how does it
even know to use either Xen, qemu etc. ?
15 years, 1 month
[libvirt] Re: OpenVZ : The restriction of domain name should be addressed
by Yuji NISHIDA
Hi Daniel,
I didn't realize that I even did not follow the manner of XML.
I have worked with this problem and got a small patch to handle "ID"
in OpenVZ functionality.
I found it is working well with the XML script included "ID" in domain
tag.
I am concerned that I had to edit the common file domain_conf.c.
I still believe I should keep it away from this problem for
compatibility with the others.
How do you think can I avoid this?
diff --git a/src/domain_conf.c b/src/domain_conf.c
index 5ae0775..f74961f 100644
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -2492,7 +2492,7 @@ static virDomainDefPtr virDomainDefParseXML
(virConnectPtr conn,
return NULL;
}
- if (!(flags & VIR_DOMAIN_XML_INACTIVE))
+ // if (!(flags & VIR_DOMAIN_XML_INACTIVE))
if((virXPathLong(conn, "string(./@id)", ctxt, &id)) < 0)
id = -1;
def->id = (int)id;
diff --git a/src/openvz_conf.c b/src/openvz_conf.c
index be94b9e..d23f173 100644
--- a/src/openvz_conf.c
+++ b/src/openvz_conf.c
@@ -425,17 +425,18 @@ int openvzLoadDomains(struct openvz_driver
*driver) {
char uuidstr[VIR_UUID_STRING_BUFLEN];
virDomainObjPtr dom = NULL;
char temp[50];
+ char name[64];
if (openvzAssignUUIDs() < 0)
return -1;
- if ((fp = popen(VZLIST " -a -ovpsid,status -H 2>/dev/null", "r"))
== NULL) {
+ if ((fp = popen(VZLIST " -a -ovpsid,name,status -H 2>/dev/null",
"r")) == NULL) {
openvzError(NULL, VIR_ERR_INTERNAL_ERROR, "%s", _("popen
failed"));
return -1;
}
while(!feof(fp)) {
- if (fscanf(fp, "%d %s¥n", &veid, status) != 2) {
+ if (fscanf(fp, "%d %s¥n", &veid, name, status) != 3) {
if (feof(fp))
break;
@@ -465,7 +466,7 @@ int openvzLoadDomains(struct openvz_driver
*driver) {
dom->pid = veid;
dom->def->id = dom->state == VIR_DOMAIN_SHUTOFF ? -1 : veid;
- if (virAsprintf(&dom->def->name, "%i", veid) < 0)
+ if (virAsprintf(&dom->def->name, "%s", name) < 0)
goto no_memory;
openvzGetVPSUUID(veid, uuidstr, sizeof(uuidstr));
diff --git a/src/openvz_driver.c b/src/openvz_driver.c
index a8c24ba..c0c1e0f 100644
--- a/src/openvz_driver.c
+++ b/src/openvz_driver.c
@@ -101,6 +101,7 @@ static int openvzDomainDefineCmd(virConnectPtr conn,
virDomainDefPtr vmdef)
{
int narg;
+ char str_id[10];
for (narg = 0; narg < maxarg; narg++)
args[narg] = NULL;
@@ -130,6 +131,11 @@ static int openvzDomainDefineCmd(virConnectPtr
conn,
ADD_ARG_LIT(VZCTL);
ADD_ARG_LIT("--quiet");
ADD_ARG_LIT("create");
+
+ sprintf( str_id, "%d", vmdef->id );
+ ADD_ARG_LIT(str_id);
+
+ ADD_ARG_LIT("--name");
ADD_ARG_LIT(vmdef->name);
if (vmdef->nfss == 1 &&
@@ -1229,7 +1235,11 @@ static int openvzListDefinedDomains
(virConnectPtr conn,
char vpsname[32];
char buf[32];
char *endptr;
- const char *cmd[] = {VZLIST, "-ovpsid", "-H", "-S", NULL};
+ const char *cmd[] = {VZLIST, "-oname", "-H", "-S", NULL};
+ int cnt = 0;
+ char name_buf[32];
+
+
/* the -S options lists only stopped domains */
ret = virExec(conn, cmd, NULL, NULL,
@@ -1241,14 +1251,14 @@ static int openvzListDefinedDomains
(virConnectPtr conn,
}
while(got < nnames){
- ret = openvz_readline(outfd, buf, 32);
+ ret = openvz_readline(outfd, buf, 64);
if(!ret) break;
- if (virStrToLong_i(buf, &endptr, 10, &veid) < 0) {
- openvzError(conn, VIR_ERR_INTERNAL_ERROR,
- _("Could not parse VPS ID %s"), buf);
- continue;
+ cnt = 0;
+ while( buf[cnt] != ' ' ){
+ name_buf[cnt] = buf[cnt];
+ cnt++;
}
- snprintf(vpsname, sizeof(vpsname), "%d", veid);
+ snprintf(vpsname, sizeof(vpsname), "%d", name_buf);
if (!(names[got] = strdup(vpsname)))
goto no_memory;
got ++;
--
1.5.2.2
-----
Yuji Nishida
nishidy(a)nict.go.jp
15 years, 1 month
[libvirt] debug output?
by Fred Leeflang
I compiled libvirtd --enable-debug=yes so I can see what's going on, because
I'm getting an error libvir: QEMU error : internal error unable to start
guest: qemu: could not open disk image.
How do I see any debugging output from libvirtd?
15 years, 1 month
[libvirt] libvirt.py
by Fred Leeflang
Hello,
Just getting started on this and checked out the source from git. Ran
autogen.sh, configure, make, make install and it doesn't seem to
automatically install libvirt.py. The generated Makefile in python/ has
these lines commented out:
#GENERATED = libvirt-export.c \
# libvirt.c \
# libvirt.h \
# libvirt.py
Am I perhaps missing some python_includes? From what I can tell,
WITH_PYTHON_TRUE only gets set to # if some includes are not there. I'm
trying to build this on Debian Lenny with Python 2.5.2
15 years, 1 month
[libvirt] [PATCH] Remove hand-crafted UUID parsers
by Daniel P. Berrange
* src/libvirt.c: Remove hand-crafted UUID parsers in favour of
calling virParseUUID
---
src/libvirt.c | 56 +++++---------------------------------------------------
1 files changed, 5 insertions(+), 51 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index 9fb0617..74d62a4 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -1839,26 +1839,11 @@ virDomainLookupByUUIDString(virConnectPtr conn, const char *uuidstr)
virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
goto error;
}
- /* XXX: sexpr_uuid() also supports 'xxxx-xxxx-xxxx-xxxx' format.
- * We needn't it here. Right?
- */
- ret = sscanf(uuidstr,
- "%02x%02x%02x%02x-"
- "%02x%02x-"
- "%02x%02x-"
- "%02x%02x-"
- "%02x%02x%02x%02x%02x%02x",
- raw + 0, raw + 1, raw + 2, raw + 3,
- raw + 4, raw + 5, raw + 6, raw + 7,
- raw + 8, raw + 9, raw + 10, raw + 11,
- raw + 12, raw + 13, raw + 14, raw + 15);
-
- if (ret!=VIR_UUID_BUFLEN) {
+
+ if (virUUIDParse(uuidstr, uuid) < 0) {
virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
goto error;
}
- for (i = 0; i < VIR_UUID_BUFLEN; i++)
- uuid[i] = raw[i] & 0xFF;
return virDomainLookupByUUID(conn, &uuid[0]);
@@ -5038,26 +5023,10 @@ virNetworkLookupByUUIDString(virConnectPtr conn, const char *uuidstr)
goto error;
}
- /* XXX: sexpr_uuid() also supports 'xxxx-xxxx-xxxx-xxxx' format.
- * We needn't it here. Right?
- */
- ret = sscanf(uuidstr,
- "%02x%02x%02x%02x-"
- "%02x%02x-"
- "%02x%02x-"
- "%02x%02x-"
- "%02x%02x%02x%02x%02x%02x",
- raw + 0, raw + 1, raw + 2, raw + 3,
- raw + 4, raw + 5, raw + 6, raw + 7,
- raw + 8, raw + 9, raw + 10, raw + 11,
- raw + 12, raw + 13, raw + 14, raw + 15);
-
- if (ret!=VIR_UUID_BUFLEN) {
+ if (virUUIDParse(uuidstr, uuid) < 0) {
virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
goto error;
}
- for (i = 0; i < VIR_UUID_BUFLEN; i++)
- uuid[i] = raw[i] & 0xFF;
return virNetworkLookupByUUID(conn, &uuid[0]);
@@ -8887,26 +8856,11 @@ virSecretLookupByUUIDString(virConnectPtr conn, const char *uuidstr)
virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
goto error;
}
- /* XXX: sexpr_uuid() also supports 'xxxx-xxxx-xxxx-xxxx' format.
- * We needn't it here. Right?
- */
- ret = sscanf(uuidstr,
- "%02x%02x%02x%02x-"
- "%02x%02x-"
- "%02x%02x-"
- "%02x%02x-"
- "%02x%02x%02x%02x%02x%02x",
- raw + 0, raw + 1, raw + 2, raw + 3,
- raw + 4, raw + 5, raw + 6, raw + 7,
- raw + 8, raw + 9, raw + 10, raw + 11,
- raw + 12, raw + 13, raw + 14, raw + 15);
-
- if (ret!=VIR_UUID_BUFLEN) {
+
+ if (virUUIDParse(uuidstr, uuid) < 0) {
virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__);
goto error;
}
- for (i = 0; i < VIR_UUID_BUFLEN; i++)
- uuid[i] = raw[i] & 0xFF;
return virSecretLookupByUUID(conn, &uuid[0]);
--
1.6.2.5
15 years, 2 months
[libvirt] Virsh migrate --live fails
by Subba Rao, Sandeep M (STSD)
Hi,
I'm trying to live move a domU using virsh migrate command:
[root@RHEL53Xen1 ~]# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Copy_RHELVM3 1 511 1 -b---- 898.3
Domain-0 0 1507 4 r----- 133702.5
[root@RHEL53Xen1 ~]# virsh migrate --live Copy_RHELVM3 xen+ssh://15.154.102.20
error: server closed connection
[root@RHEL53Xen1 ~]#
However the same works using xm migrate --live.
The source and the destination are RHEL 5.3 Xen hosts.
Libvirt:
[root@RHEL53Xen1 ~]# rpm -qa | grep libvirt
libvirt-0.3.3-14.el5
libvirt-devel-0.3.3-14.el5
libvirt-cim-0.5.1-4.el5
libvirt-python-0.3.3-14.el5
Xen:
[root@RHEL53Xen1 ~]# rpm -qa | grep xen
xen-3.0.3-80.el5
xen-libs-3.0.3-80.el5
xen-devel-3.0.3-80.el5
kernel-xen-2.6.18-128.el5
I was earlier getting the error - "can't connect: Name or service not known". So, installed libvirt-0.6.4 as mentioned in the following link:
https://bugzilla.redhat.com/show_bug.cgi?id=348861
After installing libvirt-0.6.4, I'm getting "server closed connection" error.
Any help is much appreciated.
Thanks,
Sandeep
15 years, 2 months
[libvirt] node device devicekit backend
by Dave Allan
I've been looking at implementing a libudev backed node device, and I
noticed that the devicekit node device backend doesn't build. Since I
believe DeviceKit is deprecated for this sort of use, and AFAIK the
DeviceKit support was never functionally equivalent to the HAL support,
I'm wondering if we can just drop DeviceKit support. It also drags in
glib, which is a separate problem. Opinions?
Dave
15 years, 2 months
[libvirt] Miscellaneous fixes to build with -Werror
by Charles Duffy
HACKING suggests compiling with --enable-compile-warnings=error before
submitting any patches; however, current master fails for me on this
account (CentOS 5.3; gcc 4.1.2).
Please see attached. I suspect most of these should be uncontroversial
-- but wonder if perhaps virStrcpy uses would be better converted to
virStrcpyStatic rather than adding virStrcpy to the symbol list as done
here, and am curious about whether the need for explicit initialization
to silence a warning regarding qemudSetLogging's log_level indicates a
bug in the macro later used to assign that value.
15 years, 2 months
[libvirt] Some problem with the save function
by Daniel Berteaud
Hi everyone. This is my first post to this list, so excuse me if it's
not the right place to poste info like this.
I've found some problems in qemu_driver.c in the latest versions of
libvirt:
- the first problem was also present in 0.7.0. If we run qemu guests
unprivileged, we cannot use the save function (virsh save
guestname /path/to/file). The reason seems to be that libvirt first
create the destination file to write the header and the XML definition.
The file is owned by root with 600 permission. Then, we ask qemu to
append the dump of the memory (via the migrate exec: call) to this file.
This part doesn't work because the qemu user cannot write to this file.
So we endup with a file which only contains the header and the XML, and
the guest is stoped :/
- the second problem is present since libvirt 0.7.1. Now that the saved
file can be compressed, it seems we cannot save in a raw format any
more. This is due to this part in the code (qemu_driver.c):
if (STREQ (prog, "raw"))
prog = "cat";
internalret = virAsprintf(&command, "migrate \"exec:"
"%s -c >> '%s' 2>/dev/null\"", prog,
safe_path);
which result in "migrate \"exec cat -c >> safe_path 2>/dev/null\""
But cat doesn't support the -c argument, so once again, the save fails,
as we end up with a save file which only contains the header and the XML
definition.
Unfortunately, my C knowledge is near 0, so I cannot correct this
myself.
- the third problem, is that restore doesn't work any more. I haven't
dig it yet, but when I try to restore a guest using a saved file
(uncompressed produced under libvirt 0.7.0), I've this error:
virsh restore /tmp/guest.state
error: Failed to restore domain from /tmp/guest.state
error: internal error unable to start guest:
Nothing interesting in /var/log/libvirt/qemu/guest.log:
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root
LOGNAME=root /usr/bin/qemu-kvm -S -M pc -m 2048 -smp 4 -name guest -uuid
37b5937b-eacf-fda6-f4d0-33537d61b414 -monitor
unix:/var/lib/libvirt/qemu/guest.monitor,server,nowait -localtime
-no-reboot -boot c -drive file=/dev/data/guest,if=ide,index=0,boot=on
-drive file=/var/lib/libvirt/iso/boot.iso,if=ide,media=cdrom,index=2
-net nic,macaddr=52:54:00:48:c4:ca,vlan=0,name=nic.0 -net
tap,fd=25,vlan=0,name=tap.0 -serial pty -parallel none -usb -usbdevice
tablet -vnc 127.0.0.1:0 -k fr -vga cirrus -incoming exec:cat
The qemu process eats 100% of CPU during a few seconds, then stops (if I
strace it during this time, I see a lot of error like bad file
descriptor). Anyone have save/restore functions working with 0.7.1 ?
Cheers, Daniel
--
Daniel Berteaud
FIREWALL-SERVICES SARL.
Société de Services en Logiciels Libres
Technopôle Montesquieu
33650 MARTILLAC
Tel : 05 56 64 15 32
Fax : 05 56 64 15 32
Mail: daniel(a)firewall-services.com
Web : http://www.firewall-services.com
15 years, 2 months
[libvirt] qemu_driver migrateuri handling broken?
by Gregor Schaffrath
Hi all.
Short summary on DV's request ;)
I ran into a problem migrating kvm machines with libvirt-0.6.5:
1) At first, using the same syntax for the migrateuri as with xen (just the
IP) did not work... looking into the source code (! ;) ), I found a
different syntax for qemu.
2) using tcp://<ip>:<port> just produced an 'unknown failure' on the
receiving side:
root@loadgen137:~> virsh -c qemu:///system migrate --live kvm-testnode-vnode3 qemu+tcp://10.192.11.136/system?no_verify=1 tcp://10.192.11.136:12345
error: Unknown failure
(Note: it was working like a charm when I eliminated the migrateuri
altogether, but this was not an option in all my work environments,
since one of them doesn't feature DNS, breaking migration on the
hostname alone (and keeping /etc/hosts in sync on n machines is
something I'd like to avoid, if possible ;) ))
3) removing the case distinction and the handling of the migrateuri in
the qemudDomainMigratePrepare2 function in qemu_driver.c entirely
(if-statement, and full else-part) solved both my issues.
---
The issue seems to be current with 0.7.1 as well (at least I did receive
the same error message - I did not investigate further)
---
My 2ct: ;)
I think that a wrapper like libvirt should consequently abstract
lower level details (such as 'qemu', or 'xen') as much as possible
(that's what libvirt is for, I guess :) ).
Since the removal of the URI handling solves both the issue _and_
eliminates a case distinction between xen and qemu (painlessly, as
far as I can see), I'd suggest perhaps considering the removal. :)
As to the sending side specification of transfer ports: I think there
should always be a possiblity to leave port selection up to libvirt, as
the sending side does not necessarily an oversight over the free ports
on the receiving side. (I feel that the reason for the different syntax
including mandatory :port part was motivated by the wish to allow users
to specify ports on the sending side)
Cheers,
Gregor Schaffrath.
15 years, 2 months
