[libvirt] Re: [virt-tools-list] Questions about virt-manager running on Arch of Itanium 64
by Cole Robinson
cc-ing libvirt-list
On 11/19/2009 10:35 PM, Dustin Xiong wrote:
>
>
>>> Hi everyone!
>>> I am a newer to the virt-manager and maillist. I sent the mail just want
>>> to ask some questions about virt-manager running on Arch of Itanium 64.
>>> My itanium 64 cpu actualy support the VT. I compiled the kvm85
>>> successful. Then I can use the binary /usr/local/bin/qemu-system-ia64 to
>>> create a vm and running. But in my /proc/cpuinfo , there doesn't have
>>> flags such as vmx or svm. So when I use the virt-manager to install a
>>> vm, the virt-manager will tell me my cpu doesn't support fully
>>> virtualization, then I can't install vm. In fact I can't get understand
>>> how the virt-manager find my cpu support the fully virtualization or
>>> not.In src, which file implements this.
>>>
>>
>> Just because qemu-kvm works doesn't mean virt is working on your box, since it
>> can fall back to full emulation mode. If you are trying to use kvm, is the kvm
>> module actually loaded? lsmod | grep kvm
>
> My kvm mod actually loaded.
>
> [root@kvm bin]# lsmod | grep kvm
>
> kvm_intel 306104 4294967281
>
> kvm 327544 1 kvm_intel
>
>
>
> [root@kvm bin]# modinfo kvm
>
> filename: /lib/modules/2.6.28.9hzp/extra/kvm.ko
>
> license: GPL
>
> author: Qumranet
>
> version: kvm-85
>
> srcversion: C399DD2D9B40BAAC05CD509
>
> depends:
>
> vermagic: 2.6.28.9hzp SMP mod_unload modversions ia64gcc-4.1
>
>> If so, libvirt may need to be fixed. What's the output of 'virsh --connect
>> qemu:///system capabilities'
>
> [root@kvm bin]# virsh --connect qemu:///system capabilities
> <capabilities>
>
> <host>
> <cpu>
> <arch>ia64</arch>
> </cpu>
> <topology>
> <cells num='1'>
> <cell id='0'>
> <cpus num='16'>
> <cpu id='0'/>
> <cpu id='1'/>
> <cpu id='2'/>
> <cpu id='3'/>
> <cpu id='4'/>
> <cpu id='5'/>
> <cpu id='6'/>
> <cpu id='7'/>
> <cpu id='8'/>
> <cpu id='9'/>
> <cpu id='10'/>
> <cpu id='11'/>
> <cpu id='12'/>
> <cpu id='13'/>
> <cpu id='14'/>
> <cpu id='15'/>
> </cpus>
> </cell>
> </cells>
> </topology>
> </host>
>
>
>>> My cpu is itanium 64, the OS is RHEL.The libvirt is 0.6.3, virt-manager
>>> is 0.6.1.
Ah, are you using the version of libvirt that comes with RHEL 5.4? That
version has been patched to only look for the qemu-kvm binary in one
spot: /usr/libexec/qemu-kvm IIRC. You could try to work with that, but
since you are already building upstream KVM, virt-manager, and virtinst,
might not be a bad idea to pull upstream libvirt as well.
>>> Once i tried to compile the virt-manager-0.8.0, but when i make check,
>>> it returns:
>>>
>>> PYTHONPATH=./..:../graphWidgets/.libs python addhardware.py && touch
>>> .tstamp.addhardware.py
>>> Traceback (mos! t recent call last):
>>> File "addhardware.py", line 32, in ?
>>> from virtinst import VirtualCharDevice, VirtualDevice,
>>> VirtualVideoDevice
>>>
>>> when i rpm -ivh virt-manager-0.6.1-8.el5.ia64.rpm, it could work.
>>>
>>> I don't know why this error occur. Can anyone be kind to tell me how?
>>> thanks a lot.
>>>
>>
>> You will also need to install the latest version of virtinst, found at:
>>
>> http://virt-manager.org/download.html
>
> I downloaded and compiled the latest version of virtinst: virtinst-0.500.0.tar.gz.
> then compile the virt-manager-0.8.0, error changed as below:
>
> [root@kvm virt-manager-0.8.0]# make check
> Making check in src
> make[1]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src'
> Making check in virtManager
> make[2]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager'
> make check-local
> make[3]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager'
> PYTHONPATH=./..:../graphWidgets/.libs python about.py && touch .tstamp.about.py
> PYTHONPATH=./..:../graphWidgets/.libs python addhardware.py && touch .tstamp.addhardware.py
> Traceback (most recent call last):
> File "addhardware.py", line 35, in ?
> from virtManager.asyncjob import vmmAsyncJob
> File "/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager/asyncjob.py", line 30, in ?
> class vmmAsyncJob(gobject.GObject):
> File "/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager/asyncjob.py", line 40, in vmmAsyncJob
> def __init__(self, config, callback, args=None,
> NameError: name '_' is not defined
>
> Thanks for help.If you need any further infos please dont't hesitate to tell me.
>
Ah, didn't notice the make check in the first mail. 'make check' doesn't
work in the virt-manager code base, never taken the time to fix it. You
should just be able to 'make && make install', or 'make' and python
src/virt-manager.py to run from the source dir. If running virt-manager
then throws an error, report here and Ill try to help.
- Cole
15 years, 4 months
Re: [libvirt] Segfault in event-test.c example
by pspreadborough＠comcast.net
----- "Matthias Bolte" <matthias.bolte(a)googlemail.com> wrote:
> 2010/1/10 <pspreadborough(a)comcast.net>:
> >
> > Hello,
> >
> > I have been trying to use the domain event C code example but
> > unfortunately it segfaults (signal 11) every time I run it:
> >
> > [root@Spring events-c]# ./event-test
> > myEventAddHandleFunc:221: Add handle 5 1 0xf081a0 0x8f727f8
> > myEventAddHandleFunc:221: Add handle 7 1 0xf09990 0x8f727f8
> > myEventAddHandleFunc:221: Add handle 8 1 0xed7940 0x8f727f8
> > myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0 0x8f727f8
> > myEventAddHandleFunc:221: Add handle 11 1 0xed7940 0x8f727f8
> > myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0 0x8f727f8
> > main:322 :: Registering domain event cbs
> > Segmentation fault (core dumped)
> >
> > Core was generated by
> >
> `/root/libvirt-0.7.5/examples/domain-events/events-c/.libs/lt-event-test'.
> > Program terminated with signal 11, Segmentation fault.
> > [New process 21806]
> > [New process 21822]
> > #0 remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8) at
> > remote/remote_driver.c:8720
> > 8720 tempQueue.count = priv->domainEvents->count;
> > (gdb) bt
> > #0 remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8) at
> > remote/remote_driver.c:8720
> > #1 0x080490d3 in main (argc=Cannot access memory at address 0x1
> > ) at event-test.c:347
> >
> > The stack looks corrupted so I'm doubtful that this trace if of much
> value.
> > I have built
> > and installed libvirt-0.7.5 and it and it's tools seem to be
> operating
> > correctly.
>
> I tried the event-test with libvirt-0.7.5 and QEMU/Xen and both are
> working as expected. No segfaults.
>
> Could you inspect the values of priv and priv->domainEvents in GDB
> using 'p priv' to see if they are NULL and try to dereference them in
> GDB using 'p *priv' to see if they point to valid memory areas?
>
> Yes the backtrace looks corrupted. If there is stack/heap corruption
> involved valgrind may reveal it, so try to run the event-test in
> valgrind and see if that gives any hints.
>
> You can also try the GIT version of libvirt. There was a invalid free
> call (resulting in heap corruption) in the node device code fixed
> after the 0.7.5 release. But that should have no effect on the
> event-test.
>
> Matthias
Matthias,
priv->domainEvents is NULL, here's the gdb output:
(gdb) p *priv
$1 = {lock = {lock = {__data = {__lock = 1, __count = 0, __owner = 21806, __kind = 0, __nusers = 1, {__spins = 0, __list = {
__next = 0x0}}}, __size = "\001\000\000\000\000\000\000\000.U\000\000\000\000\000\000\001\000\000\000\000\000\000",
__align = 1}}, sock = 150469168, watch = 3, pid = 4, uses_tls = 1982791681, is_secure = 1815048801, session = 0x782f6269,
type = 0x2f646e65 <Address 0x2f646e65 out of bounds>, counter = 1684956536, localUses = 1668248365,
hostname = 0x74656b <Address 0x74656b out of bounds>, debugLog = 0x0, saslconn = 0x0, saslDecoded = 0x0, saslDecodedLength = 0,
saslDecodedOffset = 0, saslEncoded = 0x0, saslEncodedLength = 0, saslEncodedOffset = 0,
buffer = '\0' <repeats 68 times>, "n\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\bQ�\b����\030\034�\b\000\000\000\000�\033�\b\001\000\000\000\002\000\000\000�\033�\b\000\000\000\000\025|�\000\a", '\0' <repeats 11 times>, "X\000�\b", '\0' <repeats 12 times>, "\021\000\000\000\002\000\000\000P��\b\000\000\000\000\021", '\0' <repeats 15 times>, "\021\000\000\0008\036�\b\f\000\000\000\020\000\000\000\021\000\000\000\a\000\000\000\b\000\000\000\t\000\000\000\021\000\000\000\002\000\000\000\230\034�\b\000\000\000\000A\000\000\000\003\000\000\000\001\000\000\000\001\000"..., bufferLength = 0,
bufferOffset = 0, callbackList = 0x0, domainEvents = 0x0, eventFlushTimer = 0, domainEventDispatching = 1, wakeupSendFD = 0,
wakeupReadFD = 0, waitDispatch = 0x0, streams = 0x0}
I'll try a run with valgrind and post the results.
Pete
15 years, 4 months
[libvirt] Segfault in event-test.c example
by pspreadborough＠comcast.net
Hello,
I have been trying to use the domain event C code example but
unfortunately it segfaults (signal 11) every time I run it:
[root@Spring events-c]# ./event-test
myEventAddHandleFunc:221: Add handle 5 1 0xf081a0 0x8f727f8
myEventAddHandleFunc:221: Add handle 7 1 0xf09990 0x8f727f8
myEventAddHandleFunc:221: Add handle 8 1 0xed7940 0x8f727f8
myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0 0x8f727f8
myEventAddHandleFunc:221: Add handle 11 1 0xed7940 0x8f727f8
myEventAddTimeoutFunc:251: Adding Timeout -1 0xedefa0 0x8f727f8
main:322 :: Registering domain event cbs
Segmentation fault (core dumped)
Core was generated by `/root/libvirt-0.7.5/examples/domain-events/events-c/.libs/lt-event-test'.
Program terminated with signal 11, Segmentation fault.
[New process 21806]
[New process 21822]
#0 remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8) at remote/remote_driver.c:8720
8720 tempQueue.count = priv->domainEvents->count;
(gdb) bt
#0 remoteDomainEventQueueFlush (timer=-1, opaque=0x8f727f8) at remote/remote_driver.c:8720
#1 0x080490d3 in main (argc=Cannot access memory at address 0x1
) at event-test.c:347
The stack looks corrupted so I'm doubtful that this trace if of much value. I have built
and installed libvirt-0.7.5 and it and it's tools seem to be operating correctly.
My setup is:
Intel(R) Pentium(R) 4 CPU 3.00GHz
Linux 2.6.18-164.10.1.el5xen #1 SMP Thu Jan 7 21:14:48 EST 2010 i686 i686 i386 GNU/Linux
virsh # version
Compiled against library: libvir 0.7.5
Using library: libvir 0.7.5
Using API: Xen 3.0.1
Running hypervisor: Xen 3.4.0
I have a project that requires Domain events so I'd very much like to use this code so
any help would be appreciated.
Regards,
Pete
15 years, 4 months
[libvirt] [PATCH] avoid another "make distcheck" failure
by Jim Meyering
"make uninstall" would fail
rm: cannot remove `/home/j/w/co/libvirt/libvirt-0.7.5/_inst/share/gtk-doc/html\
/libvirtdevhelp/libvirt.devhelp': No such file or directory
rm: cannot remove `/home/j/w/co/libvirt/libvirt-0.7.5/_inst/share/gtk-doc/html\
/libvirtdevhelp/index.html': No such file or directory
There are two problems: first, "libvirtdevhelp" is not a valid dir name.
Inserting a slash fixes that.
Second, that "devhelp/" does not belong at all.
It comes from each value of $$f. Using basename fixes that:
With this, "make distcheck" passes once again.
Pushed.
>From 0418fa2e7265d6cf938f2172a0aeb9f9d7a93022 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering(a)redhat.com>
Date: Sat, 9 Jan 2010 09:56:20 +0100
Subject: [PATCH] avoid another "make distcheck" failure
* docs/Makefile.am (uninstall-local): Separate $$f from preceding
dir name with a "/" and use $$(basename $$f) rather than $$f, since
some values of $$f are prefixed with devhelp/.
---
docs/Makefile.am | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/docs/Makefile.am b/docs/Makefile.am
index d53f305..c19e963 100644
--- a/docs/Makefile.am
+++ b/docs/Makefile.am
@@ -159,4 +159,5 @@ uninstall-local:
for h in $(apihtml); do rm $(DESTDIR)$(HTML_DIR)/$$h; done
for p in $(apipng); do rm $(DESTDIR)$(HTML_DIR)/$$p; done
for f in $(devhelphtml) $(devhelppng) $(devhelpcss); do \
- rm $(DESTDIR)$(DEVHELP_DIR)$$f ; done
+ rm $(DESTDIR)$(DEVHELP_DIR)/$$(basename $$f); \
+ done
--
1.6.6.439.gaf68f
15 years, 4 months
[libvirt] [PATCH] fix 7 "make check" test failures in non-srcdir build
by Jim Meyering
FYI, I've already pushed this.
When I ran "make distcheck" (or just a non-srcdir "make check"),
I'd get 7 failures. These were introduced by a change back in October.
>From e6abf3d8f2a60249955c4d59e7b994a99faf8ace Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering(a)redhat.com>
Date: Sat, 9 Jan 2010 08:37:22 +0100
Subject: [PATCH] fix 7 "make check" test failures in non-srcdir build
* tests/capabilityschematest: Define and use $srcdir.
* tests/domainschematest: Likewise.
* tests/interfaceschematest: Likewise.
* tests/networkschematest: Likewise.
* tests/nodedevschematest: Likewise.
* tests/storagepoolschematest: Likewise.
* tests/storagevolschematest: Likewise.
---
tests/capabilityschematest | 3 ++-
tests/domainschematest | 3 ++-
tests/interfaceschematest | 3 ++-
tests/networkschematest | 3 ++-
tests/nodedevschematest | 3 ++-
tests/storagepoolschematest | 3 ++-
tests/storagevolschematest | 3 ++-
7 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/tests/capabilityschematest b/tests/capabilityschematest
index 3a1acc5..482dfe3 100755
--- a/tests/capabilityschematest
+++ b/tests/capabilityschematest
@@ -1,6 +1,7 @@
#!/bin/sh
-. ./schematestutils.sh
+: ${srcdir=.}
+. $srcdir/schematestutils.sh
DIRS="capabilityschemadata xencapsdata"
SCHEMA="capability.rng"
diff --git a/tests/domainschematest b/tests/domainschematest
index 28ee69a..27a93cf 100755
--- a/tests/domainschematest
+++ b/tests/domainschematest
@@ -1,6 +1,7 @@
#!/bin/sh
-. ./schematestutils.sh
+: ${srcdir=.}
+. $srcdir/schematestutils.sh
DIRS="domainschemadata qemuxml2argvdata sexpr2xmldata xmconfigdata xml2sexprdata"
SCHEMA="domain.rng"
diff --git a/tests/interfaceschematest b/tests/interfaceschematest
index e9ec2a4..8e9f6ee 100755
--- a/tests/interfaceschematest
+++ b/tests/interfaceschematest
@@ -1,6 +1,7 @@
#!/bin/sh
-. ./schematestutils.sh
+: ${srcdir=.}
+. $srcdir/schematestutils.sh
DIRS="interfaceschemadata"
SCHEMA="interface.rng"
diff --git a/tests/networkschematest b/tests/networkschematest
index 01b2e6f..7210055 100755
--- a/tests/networkschematest
+++ b/tests/networkschematest
@@ -1,6 +1,7 @@
#!/bin/sh
-. ./schematestutils.sh
+: ${srcdir=.}
+. $srcdir/schematestutils.sh
DIRS="../src/network networkxml2xmlin networkxml2xmlout"
SCHEMA="network.rng"
diff --git a/tests/nodedevschematest b/tests/nodedevschematest
index 2f0e2b9..3f0f03f 100755
--- a/tests/nodedevschematest
+++ b/tests/nodedevschematest
@@ -1,6 +1,7 @@
#!/bin/sh
-. ./schematestutils.sh
+: ${srcdir=.}
+. $srcdir/schematestutils.sh
DIRS="nodedevschemadata"
SCHEMA="nodedev.rng"
diff --git a/tests/storagepoolschematest b/tests/storagepoolschematest
index 57b2f7b..9aef382 100755
--- a/tests/storagepoolschematest
+++ b/tests/storagepoolschematest
@@ -1,6 +1,7 @@
#!/bin/sh
-. ./schematestutils.sh
+: ${srcdir=.}
+. $srcdir/schematestutils.sh
DIRS="storagepoolxml2xmlin storagepoolxml2xmlout"
SCHEMA="storagepool.rng"
diff --git a/tests/storagevolschematest b/tests/storagevolschematest
index 32a8657..74b6203 100755
--- a/tests/storagevolschematest
+++ b/tests/storagevolschematest
@@ -1,6 +1,7 @@
#!/bin/sh
-. ./schematestutils.sh
+: ${srcdir=.}
+. $srcdir/schematestutils.sh
DIRS="storagevolxml2xmlin storagevolxml2xmlout"
SCHEMA="storagevol.rng"
--
1.6.6.439.gaf68f
15 years, 4 months
[libvirt] [PATCH] avoid newly-introduced test failure
by Jim Meyering
I ran "make check" and was surprised to see a failure:
10) QEMU XML-2-ARGV hugepages ... FAILED
...
FAIL: qemuxml2argvtest
Introduced just a couple days ago.
Here's the fix:
>From a4e9edbd77f428782293b9672098b6d3c80b2879 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering(a)redhat.com>
Date: Sat, 9 Jan 2010 09:25:04 +0100
Subject: [PATCH] avoid newly-introduced test failure
* tests/qemuxml2argvdata/qemuxml2argv-hugepages.args: Update
expected output to match, now that we use -mem-prealloc.
---
tests/qemuxml2argvdata/qemuxml2argv-hugepages.args | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-hugepages.args b/tests/qemuxml2argvdata/qemuxml2argv-hugepages.args
index f10a40e..1e2632a 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-hugepages.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-hugepages.args
@@ -1 +1 @@
-LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -mem-path /dev/hugepages/libvirt/qemu -smp 1 -nographic -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb
+LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -mem-prealloc -mem-path /dev/hugepages/libvirt/qemu -smp 1 -nographic -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb
--
1.6.6.439.gaf68f
In case you can't read the above, note that all the change
does is to insert "-mem-prealloc " before "-mem-path"
I'm about to push this, now.
15 years, 4 months
[libvirt] Some questions about the libvirt ESX driver
by Richard W.M. Jones
I'm playing with VMWare ESX 4.0 and I decided to try driving it from
libvirt [git version]. Here are some random questions and issues I
encountered, in no particular order.
Listing domains works fine, but:
(a) I have to specify ?no_verify=1 to get it to ignore the lack of
valid https certificate. Is there some documentation on how to set up
certificates correctly? [vSphere gives exactly the same error]
(b) I have to type the root password (of the ESX server) each time.
Can I avoid that?
$ sudo ./tools/virsh -c 'esx://192.168.2.121/?no_verify=1' list --all
Enter username for 192.168.2.121 [root]:
Enter root password for 192.168.2.121:
Id Name State
----------------------------------
- TestLinux shut off
- TestWin shut off
(c) Starting domains doesn't seem to work, and the error message is
obscure:
$ sudo ./tools/virsh -c 'esx://192.168.2.121/?no_verify=1' start TestLinux
Enter username for 192.168.2.121 [root]:
Enter root password for 192.168.2.121:
error: Failed to start domain TestLinux
error: internal error HTTP response code 500 for call to 'PowerOnVM_Task'. Fault: ServerFaultCode - The operation is not allowed in the current state.
Is this to do with the "ask questions" API that was discussed on this
list before? Specifying auto_answer=0 or auto_answer=1 didn't make
any difference.
(d) dumpxml XML output looks very good, and consistent with the other
drivers. However it produces an odd <source file> attribute:
<disk type='file' device='disk'>
<driver name='lsilogic'/>
<source file='[Storage1] TestLinux/TestLinux.vmdk'/>
<target dev='sda' bus='scsi'/>
</disk>
<disk type='file' device='cdrom'>
<source file='[Storage1] Fedora-12-x86_64-Live.iso'/>
<target dev='hdc' bus='ide'/>
</disk>
(e) pool-list, net-list are not supported by the driver.
That's a particular problem for me because I was really hoping to use
the storage APIs from libvirt to access the VMDK files that contain
domains (eg. [Storage1] TestLinux/TestLinux.vmdk in the example
above). Is support for storage (particularly) and/or networks on the
horizon for this driver?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
15 years, 4 months
[libvirt] [PATCH] esx: Warn if the ESX server is in maintenance mode
by Matthias Bolte
---
src/esx/esx_driver.c | 38 +++++++++++++++++++++++++++-----------
1 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
index f86654a..ddda66e 100644
--- a/src/esx/esx_driver.c
+++ b/src/esx/esx_driver.c
@@ -401,6 +401,32 @@ esxOpen(virConnectPtr conn, virConnectAuthPtr auth, int flags ATTRIBUTE_UNUSED)
}
}
+ /* Query the host for maintenance mode and vCenter IP address */
+ if (esxVI_String_AppendValueListToList(conn, &propertyNameList,
+ "runtime.inMaintenanceMode\0"
+ "summary.managementServerIp\0") < 0 ||
+ esxVI_LookupHostSystemByIp(conn, priv->host, hostIpAddress,
+ propertyNameList, &hostSystem) < 0) {
+ goto failure;
+ }
+
+ /* Warn if host is in maintenance mode */
+ for (dynamicProperty = hostSystem->propSet; dynamicProperty != NULL;
+ dynamicProperty = dynamicProperty->_next) {
+ if (STREQ(dynamicProperty->name, "runtime.inMaintenanceMode")) {
+ if (esxVI_AnyType_ExpectType(conn, dynamicProperty->val,
+ esxVI_Type_Boolean) < 0) {
+ goto failure;
+ }
+
+ if (dynamicProperty->val->boolean == esxVI_Boolean_True) {
+ VIR_WARN0("The server is in maintenance mode");
+ }
+
+ break;
+ }
+ }
+
/* Login to vCenter */
if (vCenter != NULL) {
VIR_FREE(url);
@@ -415,17 +441,9 @@ esxOpen(virConnectPtr conn, virConnectAuthPtr auth, int flags ATTRIBUTE_UNUSED)
}
/* Lookup the vCenter from the ESX host */
- if (esxVI_String_AppendValueToList
- (conn, &propertyNameList, "summary.managementServerIp") < 0 ||
- esxVI_LookupHostSystemByIp(conn, priv->host, hostIpAddress,
- propertyNameList, &hostSystem) < 0) {
- goto failure;
- }
-
for (dynamicProperty = hostSystem->propSet; dynamicProperty != NULL;
dynamicProperty = dynamicProperty->_next) {
- if (STREQ(dynamicProperty->name,
- "summary.managementServerIp")) {
+ if (STREQ(dynamicProperty->name, "summary.managementServerIp")) {
if (esxVI_AnyType_ExpectType(conn, dynamicProperty->val,
esxVI_Type_String) < 0) {
goto failure;
@@ -461,8 +479,6 @@ esxOpen(virConnectPtr conn, virConnectAuthPtr auth, int flags ATTRIBUTE_UNUSED)
}
break;
- } else {
- VIR_WARN("Unexpected '%s' property", dynamicProperty->name);
}
}
--
1.6.0.4
15 years, 4 months
[libvirt] RFC: Create a separate libvirt users mailing list ?
by Daniel P. Berrange
Hi Folks,
We've been brainstorming ways to improve/broaden the libvirt community
and one (of many) ideas is to create a separate libvirt users mailing
list. The rationale is that this list is 95% patch submission from
developers, often very high traffic and thus it may not be appealing for
ordinary users to subscribe just to ask a question about libvirt usage.
Although there is the virt-tools mailing list, that is really focused
on the virt-manager family of apps, not a general purpose libvirt users
community.
Thus we're considering creating a new list
libvirt-users(a)redhat.com
To serve as a home for discussions relating to
- Administrators/users of libvirt / libvirtd / virsh
- Developers building applications on top of libvirt
- Anyone else wishing to ask/talk about libvirt architecture /
concepts / etc in real world deployment
While the current list
libvir-list(a)redhat.com
To serve as continued home for most current traffic, specifically
- Development of libvirt itself (libvirtd, hypervisor drivers, etc)
- Development of libvirt language bindings (perl, python, java, etc)
- Patch submission for libvirt & language bindings
Essentially all libvirt code patches would be on libvir-list, while
libvirt-users would be for app developer / end user admin discussions.
For this to work of course, a significant number developers of libvirt
currently on this list would also have to join libvirt-users, so we have
people on the new list who are able to answer questions :-)
Before we create a new list we'd like to hear from people on this list as
to wether they think this would be beneficial. In particular we'd like your
opinion if you are someone who's likely to switch to be exclusively on
the libvirt-users list.
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 :|
15 years, 4 months
Re: [libvirt] pci-stub error and MSI-X for KVM guest
by Chris Wright
* Fischer, Anna (anna.fischer(a)hp.com) wrote:
> So, when setting a breakpoint for the exit() call I'm getting a bit closer to figuring where it kills my guest.
Thanks, this helps clarify what is happening.
> Breakpoint 1, exit (status=1) at exit.c:99
> 99 {
> Current language: auto
> The current source language is "auto; currently c".
> (gdb) bt
> #0 exit (status=1) at exit.c:99
> #1 0x0000000000470c6e in assigned_dev_pci_read_config (d=0x259c6f0, address=64, len=4)
assigned_dev_pci_read_config(..., 64, 4)
^^
This is a libvirt issue. When you use virt-manager it has libvirtd
fork/exec qemu-kvm. libvirtd will drop privileges and run qemu-kvm as
user qemu (or perhaps root if you've edited qemu.conf). Regardless of
the user, it clears capabilities. Reading PCI config space beyond just
the header requires CAP_SYS_ADMIN. The above is reading the first 4
bytes of device dependent config space, and the kernel is returning 0
because qemu doesn't have CAP_SYS_ADMIN.
Basically, this means that device assignment w/ libvirt will break
MSI/MSI-X because qemu will never be able to see that the host device
has those PCI capabilities. This, in turn, renders VF device assignment
useless (since a VF is required to support MSI and/or MSI-X).
Granting CAP_SYS_ADMIN for each qemu instance that does device assignment
would render the privilege reduction useless (CAP_SYS_ADMIN is the
kitchen sink catchall of the Linux capability system).
Hmmph...
15 years, 4 months