[libvirt] [PATCH] vbox: don't fail on missing vbox
by Guido Günther
Hi,
virsh fails with:
10:47:37.104: debug : do_open:922 : no name, allowing driver auto-select
10:47:37.104: debug : do_open:930 : trying driver 0 (Test) ...
10:47:37.104: debug : do_open:936 : driver 0 Test returned DECLINED
10:47:37.104: debug : do_open:930 : trying driver 1 (OPENVZ) ...
10:47:37.105: debug : do_open:936 : driver 1 OPENVZ returned DECLINED
10:47:37.105: debug : do_open:930 : trying driver 2 (VBOX) ...
10:47:37.106: debug : do_open:936 : driver 2 VBOX returned ERROR
10:47:37.106: debug : virUnrefConnect:210 : unref connection 0x10032b10 1
10:47:37.106: debug : virReleaseConnect:171 : release connection 0x10032b10
error: failed to connect to the hypervisor
if one has built with vbox support but vbox is not installed. Attached
patch calls VBoxCGlueInit() early so we can return 'declined' instead of
'error'. O.k. to apply?
-- Guido
16 years
[libvirt] Libvirt-Java Binding
by Marcel Michelmann
Hello,
I created a program in Java for communicating with a libvirt/XEN host over
SSH. For every update I create a new connection.
It just runs about 1 1/2 minutes. I guess it is because I do not close any
of these connections.
When I tried to close them after having used them (Connect.close()) the
program hangs. But after pressing Ctrl+C the program stops and the results
are shown.
Is that a bug in the libvirt-Java binding? Does anybody else have the same
problem with Connect.close()?
Thanks,
Marcel
16 years
[libvirt] using public vir*Free() (instead of virUnref*()) from vir*FreeName() destructors.
by Laine Stump
I just noticed in datatypes.c that the
vir(Network|StoragePool|StorageVol)FreeName destructors call the public
API vir*Free() functions rather than the local virUnref*(). vir*Free()
all clear any errors, which seems like it might not be the right thing
to do (eg, if we're cleaning out the hashtables as part of some
error-handling path, and haven't yet logged the error).
On the other hand, the public API function does some sanity checking on
the object to make sure it really is what we think it is before calling
the unref. So it's got that going for it. (5 points to anyone who
catches the reference without going to Google) But I don't know enough
to know whether or not that's important in this case.
So which is more important: the extra sanity check, or not clearing
existing error codes?
16 years
[libvirt] PCI Passthrough
by Aaron Clausen
I'm having a heck of a time trying to figure out how to do PCI
passthrough for a PCI SCSI controller. I need, if at all possible, to
access it so that I can use a SCSI tape drive with a Windows Server
2000 guest. This is xml config I have:
<domain type='kvm'>
<name>testserver</name>
<uuid>f75a2f63-e1bd-72a5-6134-3fcafbcdb970</uuid>
<memory>524288</memory>
<currentMemory>524288</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='pc'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<pae/>
</features>
<clock offset='localtime'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<source file='/var/lib/libvirt/images/testserver.img'/>
<target dev='hda' bus='ide'/>
</disk>
<disk type='block' device='cdrom'>
<source dev='/dev/cdrom'/>
<target dev='hdc' bus='ide'/>
<readonly/>
</disk>
<interface type='bridge'>
<mac address='54:52:00:50:03:08'/>
<source bridge='br0'/>
<target dev='vnet2'/>
</interface>
<serial type='pty'>
<source path='/dev/pts/7'/>
<target port='0'/>
</serial>
<console type='pty' tty='/dev/pts/7'>
<source path='/dev/pts/7'/>
<target port='0'/>
</console>
<input type='tablet' bus='usb'/>
<input type='mouse' bus='ps2'/>
<graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
</devices>
</domain>
--
Aaron Clausen
mightymartianca(a)gmail.com
16 years
[libvirt] Virsh list on xen after stop/restart not working properly
by Thomas Graves
Hello,
I am seeing an issue on libvirt 0.6.1 and 0.6.3 with xen3.3.1 where virsh
list -all isn't reporting all vms that are active. It happens after you
shutdown and then restart a vm. As a side note, it works fine on libvirt
0.3.3.
It appears that the domid of the vm is changed when you shutdown/restart a
vm on xen. Libvirt is checking xenstore to find domids and it is finding the
old ones that are marked as cancelled and not finding the higher number ones
that are active/valid.
Has anyone seen this issue and have a patch for it?
It looks like the old libvirt 0.3.3 went to the hypervisor and xend before
the xenstore and that is working properly.
Thanks,
Tom
16 years
[libvirt] KVM processes -- should we be able to attach them to the libvirtd process?
by Hugh O. Brock
Not too long ago we took a patch that allowed QEMU VMs to keep running
even if libvirtd died or was restarted.
I was talking to Matt Farellee (cc'd) this afternoon about
manageability, and he feels fairly strongly that this behavior should be
optional -- in other words, it should be possible to guarantee that if
libvirtd dies, it will take all the VMs with the "die-with-libvirtd"
flag set down with it.
I'm not sure this API is portable to Xen, but it would work on any
hypervisor that represents the VM as a normal process.
Does this strike anyone else as useful behavior?
Thanks,
--Hugh
16 years
[libvirt] Java api for libvirt migration
by Zvi Dubitzky
I am trying to do a migrate of VM with libvirt 0.6.1 and kvm-84 . I am
successful in doing it many times via the C interface .
I can do most of the basic libvirt activity via the libvirt JAVA library
(libvirt-java-0.2.1). When it comes to a migrate the JVM fails wit a log
file
attached below . Can someone help. My memory consumption in my JAVA test
code is small.
The migrate parameters I am sending with the Java are identical to
those I use in the C case and is:
destDomain = localDomain.migrate (dcon, // destination
host Connect object
VIR_MIGRATE_LIVE,
null, //const char *dname
destination domain name
target_uri,
//"tcp:9.148.28.13:4444"
0 //
unsigned long bandwidth) - do not specify
);
thanks
Zvi Dubitzky
Virtualization and System Architecture Email:dubi@il.ibm.com
IBM Haifa Research Laboratory Phone: +972-4-8296182
Haifa, 31905, ISRAEL
16 years
