[libvirt] [PATCH] OpenVZ xml refactoring
by Evgeniy Sokolov
Patch switch OpenVZ XML format to generic.
main changes:
- I used generic virDomainNetDef to define network in container.
And wrote function to apply virDomainNetDef for container.
Method virDomainNetDefParseXML is public now.
- tag "container" is changed to "devices"
- changed format of tag "filesystem"
- added processing "vcpu" tag.
15 years, 9 months
[libvirt] Re: kexec/kdump of a kvm guest?
by Mike Snitzer
On Thu, Jul 24, 2008 at 9:15 AM, Vivek Goyal <vgoyal(a)redhat.com> wrote:
> On Thu, Jul 24, 2008 at 07:49:59AM -0400, Mike Snitzer wrote:
>> On Thu, Jul 24, 2008 at 4:39 AM, Alexander Graf <agraf(a)suse.de> wrote:
>> > As you're stating that the host kernel breaks with kvm modules loaded, maybe
>> > someone there could give a hint.
>>
>> OK, I can try using a newer kernel on the host too (e.g. 2.6.25.x) to
>> see how kexec/kdump of the host fairs when kvm modules are loaded.
>>
>> On the guest side of things, as I mentioned in my original post,
>> kexec/kdump wouldn't work within a 2.6.22.19 guest with the host
>> running 2.6.25.4 (with kvm-70).
>>
>
> Hi Mike,
>
> I have never tried kexec/kdump inside a kvm guest. So I don't know if
> historically they have been working or not.
Avi indicated he seems to remember that at least kexec worked last he
tried (didn't provide when/what he tried though).
> Having said that, Why do we need kdump to work inside the guest? In this
> case qemu should be knowing about the memory of guest kernel and should
> be able to capture a kernel crash dump? I am not sure if qemu already does
> that. If not, then probably we should think about it?
>
> To me, kdump is a good solution for baremetal but not for virtualized
> environment where we already have another piece of software running which
> can do the job for us. We will end up wasting memory in every instance
> of guest (memory reserved for kdump kernel in every guest).
I haven't looked into what mechanics qemu provides for collecting the
entire guest memory image; I'll dig deeper at some point. It seems
the libvirt mid-layer ("virsh dump" - dump the core of a domain to a
file for analysis) doesn't support saving a kvm guest core:
# virsh dump guest10 guest10.dump
libvir: error : this function is not supported by the hypervisor:
virDomainCoreDump
error: Failed to core dump domain guest10 to guest10.dump
Seems that libvirt functionality isn't available yet with kvm (I'm
using libvirt 0.4.2, I'll give libvirt 0.4.4 a try). cc'ing the
libvirt-list to get their insight.
That aside, having the crash dump collection be multi-phased really
isn't workable (that is if it requires a crashed guest to be manually
saved after the fact). The host system _could_ be rebooted; whereby
losing the guest's core image. So automating qemu and/or libvirtd to
trigger a dump would seem worthwhile (maybe its already done?).
So while I agree with you its ideal to not have to waste memory in
each guest for the purposes of kdump; if users want to model a guest
image as closely as possible to what will be deployed on bare metal it
really would be ideal to support a 1:1 functional equivalent with kvm.
I work with people who refuse to use kvm because of the lack of
kexec/kdump support.
I can do further research but welcome others' insight: do others have
advice on how best to collect a crashed kvm guest's core?
> It will be interesting to look at your results with 2.6.25.x kernels with
> kvm module inserted. Currently I can't think what can possibly be wrong.
If the host's 2.6.25.4 kernel has both the kvm and kvm-intel modules
loaded kexec/kdump does _not_ work (simply hangs the system). If I
only have the kvm module loaded kexec/kdump works as expected
(likewise if no kvm modules are loaded at all). So it would appear
that kvm-intel and kexec are definitely mutually exclusive at the
moment (at least on both 2.6.22.x and 2.6.25.x).
Mike
15 years, 10 months
[libvirt] virsh
by drew einhorn
Hi,
I have virsh running in a remote ssh session in a dom0 xen VM,
it is presenting a virtual console for a domU vm
running a RHEL5 installer
The RHEL5 is going astray setting up the network using DHCP,
I want to do Ctrl-Alt-Fn to view the installer log files, and access a shell
prompt.
But the Ctrl-Alt-Fn is being consumed by the laptop running the remote ssh
ssh session.
How do I get the virsh to send Ctrl-Alt-Fn to the domU console?
--
Drew Einhorn
15 years, 10 months
[libvirt] Problems when using libvirt-cim provider
by SHAN, CHUN -HCHBJ
Hi,all:
I am trying to use libvirt API and libvirt-cim now. After installed them successfully, I can see the "Virt_*****" providers using "cimprovider -l -s"commond. My cimom is pegasus.
Then I used wbemcli as cim client. But when I used "wbemcli ei" to enumerate instances of a specified class,for example,Xen_DiskPool, error code was:
wbemcli:Cim(1) CIM_ERR_FAILED: A general error occurred that is not covered by a more specific error code:"For provider Virt_DevicePool the library name was empty. Check provider registered location".
Could you please help me to solve this problem? Did it mean that the providers were not registered correctly? But I "make postinstall" the provider and no errors occourred.
Thank you!
Regards,
Chun Shan
Disclaimer:
The contents of this e-mail, and its attachments, if any, are confidential and may be protected
by law against any unauthorized use. If you have received this e-mail by mistake or have
reason to believe that you are not the intended recipient, please notify the sender by reply
e-mail as soon as possible and delete it from your computer system immediately thereafter.
If you are not the intended recipient, you must not copy this e-mail or attachment or disclose
the contents to any other person. While we have made every effort to keep our network virus free,
we take no responsibility for any computer virus which might be transferred by way of this e-mail.
15 years, 10 months
[libvirt] PATCH Remove unused openvz code
by Daniel P. Berrange
The openvz driver currrently generates a compile warning due to this
unused function. If no one objects I'll shortly remove it.
I intend to turn on openvz and LXC driver compilation for the nightly
builds to get more testing coverage
Daniel
diff -r 59140de4e7a9 src/openvz_driver.c
--- a/src/openvz_driver.c Mon Jul 21 18:27:29 2008 +0100
+++ b/src/openvz_driver.c Tue Jul 22 22:12:22 2008 +0100
@@ -91,32 +91,11 @@
unsigned int flags ATTRIBUTE_UNUSED);
static int openvzDomainUndefine(virDomainPtr dom);
-static int convCmdbufExec(char cmdbuf[], char *cmdExec[]);
static void cmdExecFree(char *cmdExec[]);
static int openvzGetProcessInfo(unsigned long long *cpuTime, int vpsid);
struct openvz_driver ovz_driver;
-
-static int convCmdbufExec(char cmdbuf[], char *cmdExec[])
-{
- int i=0, limit = OPENVZ_MAX_ARG - 1;
- char cmdWord[CMDOP_LEN];
- while(*cmdbuf)
- {
- if(i >= limit)
- {
- cmdExec[i] = NULL;
- return -1;
- }
- sscanf(cmdbuf, "%s", cmdWord);
- cmdbuf += strlen(cmdWord);
- while(*cmdbuf == ' ') cmdbuf++;
- cmdExec[i++] = strdup(cmdWord);
- }
- cmdExec[i] = NULL;
- return i;
-}
static void cmdExecFree(char *cmdExec[])
{
--
|: 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, 10 months
[libvirt] Couple qemu driver bugs after xml refactoring
by Cole Robinson
Hi all,
I've hit a couple bugs in the qemu driver with the recent
domain xml refactoring. I've debugged them but in both
cases I'm not sure what the optimal solutions are, so I'm
just laying them out here:
1) Previously defining a qemu guest without a 'listen'
address specified in the graphics tag would default to
127.0.0.1 (hardcoded in qemu_driver->vncListen). Current
xml doesn't set this default, and will build a qemu
command line with an entry like '-vnc (null):1'. Not
sure if the default should be set at the parsing level
or the driver level.
2) If a cpuset isn't specified, def->cpumask is null.
However qemudInitCpus from qemu_driver.c doesn't know
how to handle this, causing libvirtd to crash. This
function is also using QEMUD_CPUMASK_LEN which I think
should be replaced with VIR_DOMAIN_CPUMASK_LEN. I tried
the obvious fix of just skipping the dependent code
if cpumask is null, but there still seemed to be problems
and I didn't dig much deeper.
Thanks,
Cole
15 years, 10 months
[libvirt] Double free in test driver error handling (0.4.4)
by Tóth István
While debugging the libvirt-java error handling problem, Ive found that
if I call the test driver with a bad uri, the application instantly
bombs with a
double free error.
Try to run the attached test program to trigger the bug.
regards
István
#include <libvirt/libvirt.h>
#include <stdio.h>
int main(){
int ret=virInitialize();
virConnectOpen("test:///defaultt");
}
15 years, 10 months
