- Users - libvirt List Archives

[libvirt-users] Problem starting libvirtd 0.9.3 on Ubuntu
by Heath Petersen 13 Jul '11

13 Jul '11

I just built libvirt 0.9.3 from scratch on my Ubuntu 10.10 system. It appeared to build and install correctly. When running a command like 'virsh -c qemu:///session list --all', I get the following: error: Failed to connect socket to '@/home/heath/.libvirt/libvirt-sock': Connection refused error: failed to connect to the hypervisor When looking into it, I realized libvirtd was not running as user heath after the command. Running it with LIBVIRT_DEBUG=1, I get: ... 22:26:34.334: 8385: debug : remoteOpen:774 : Auto-spawn user daemon instance 22:26:34.334: 8385: debug : doRemoteOpen:487 : proceeding with name = qemu:///session 22:26:34.334: 8385: debug : doRemoteOpen:497 : Connecting with transport 1 22:26:34.378: 8385: debug : doRemoteOpen:544 : Proceeding with sockname @/home/heath/.libvirt/libvirt-sock 22:26:34.378: 8385: debug : virCommandRunAsync:1874 : About to run LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games HOME=/home/heath USER=heath LOGNAME=heath /usr/local/sbin/libvirtd --timeout=30 22:26:34.378: 8385: debug : virCommandRunAsync:1890 : Command result 0, with PID 8386 22:26:34.379: 8385: debug : virCommandRun:1711 : Result status 0, stdout: '(null)' stderr: '(null)' 22:26:55.430: 8385: debug : do_open:1059 : driver 7 remote returned ERROR 22:26:55.430: 8385: debug : virUnrefConnect:145 : unref connection 0x8451840 1 22:26:55.430: 8385: debug : virReleaseConnect:94 : release connection 0x8451840 error: Failed to connect socket to '@/home/heath/.libvirt/libvirt-sock': Connection refused error: failed to connect to the hypervisor I then tried to start libvirtd manually with 'LIBVIRT_DEBUG=1 LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games HOME=/home/heath USER=heath LOGNAME=heath /usr/local/sbin/libvirtd --timeout=30', just like it appears virsh is trying to do. I get a return code of 1 with the following output: 22:29:33.295: 8389: info : libvirt version: 0.9.3 22:29:33.295: 8389: debug : virInitialize:412 : register drivers 22:29:33.295: 8389: debug : virRegisterDriver:767 : driver=0x3745e0 name=Test 22:29:33.295: 8389: debug : virRegisterDriver:791 : registering Test as driver 0 22:29:33.295: 8389: debug : virRegisterNetworkDriver:584 : registering Test as network driver 0 22:29:33.295: 8389: debug : virRegisterInterfaceDriver:617 : registering Test as interface driver 0 22:29:33.295: 8389: debug : virRegisterStorageDriver:650 : registering Test as storage driver 0 22:29:33.295: 8389: debug : virRegisterDeviceMonitor:683 : registering Test as device driver 0 22:29:33.295: 8389: debug : virRegisterSecretDriver:716 : registering Test as secret driver 0 22:29:33.295: 8389: debug : virRegisterNWFilterDriver:749 : registering Test as network filter driver 0 22:29:33.295: 8389: debug : virRegisterDriver:767 : driver=0x374fa0 name=Xen 22:29:33.295: 8389: debug : virRegisterDriver:791 : registering Xen as driver 1 22:29:33.295: 8389: debug : virRegisterDriver:767 : driver=0x375720 name=OPENVZ 22:29:33.295: 8389: debug : virRegisterDriver:791 : registering OPENVZ as driver 2 22:29:33.295: 8389: debug : virRegisterDriver:767 : driver=0x375920 name=VMWARE 22:29:33.295: 8389: debug : virRegisterDriver:791 : registering VMWARE as driver 3 22:29:33.295: 8389: debug : virRegisterDriver:767 : driver=0x375420 name=PHYP 22:29:33.295: 8389: debug : virRegisterDriver:791 : registering PHYP as driver 4 22:29:33.295: 8389: debug : virRegisterStorageDriver:650 : registering PHYP as storage driver 1 22:29:33.295: 8389: debug : virRegisterInterfaceDriver:617 : registering PHYP as interface driver 1 22:29:33.324: 8389: debug : tryLoadOne:163 : Found VBoxXPCOMC.so in '/usr/lib/virtualbox' 22:29:33.324: 8389: debug : vboxRegister:94 : VBoxCGlueInit found API version: 4.0.10 (4000010) 22:29:33.324: 8389: debug : vboxRegister:121 : VirtualBox API version: 4.0 22:29:33.324: 8389: debug : virRegisterDriver:767 : driver=0x376920 name=VBOX 22:29:33.324: 8389: debug : virRegisterDriver:791 : registering VBOX as driver 5 22:29:33.324: 8389: debug : virRegisterNetworkDriver:584 : registering VBOX as network driver 1 22:29:33.325: 8389: debug : virRegisterStorageDriver:650 : registering VBOX as storage driver 2 22:29:33.325: 8389: debug : virRegisterDriver:767 : driver=0x376c20 name=ESX 22:29:33.325: 8389: debug : virRegisterDriver:791 : registering ESX as driver 6 22:29:33.325: 8389: debug : virRegisterInterfaceDriver:617 : registering ESX as interface driver 2 22:29:33.325: 8389: debug : virRegisterNetworkDriver:584 : registering ESX as network driver 2 22:29:33.325: 8389: debug : virRegisterStorageDriver:650 : registering ESX as storage driver 3 22:29:33.325: 8389: debug : virRegisterDeviceMonitor:683 : registering ESX as device driver 1 22:29:33.325: 8389: debug : virRegisterSecretDriver:716 : registering ESX as secret driver 1 22:29:33.325: 8389: debug : virRegisterNWFilterDriver:749 : registering ESX as network filter driver 1 22:29:33.325: 8389: debug : virRegisterDriver:767 : driver=0x374a00 name=remote 22:29:33.325: 8389: debug : virRegisterDriver:791 : registering remote as driver 7 22:29:33.325: 8389: debug : virRegisterNetworkDriver:584 : registering remote as network driver 3 22:29:33.325: 8389: debug : virRegisterInterfaceDriver:617 : registering remote as interface driver 3 22:29:33.325: 8389: debug : virRegisterStorageDriver:650 : registering remote as storage driver 4 22:29:33.325: 8389: debug : virRegisterDeviceMonitor:683 : registering remote as device driver 2 22:29:33.325: 8389: debug : virRegisterSecretDriver:716 : registering remote as secret driver 2 22:29:33.325: 8389: debug : virRegisterNWFilterDriver:749 : registering remote as network filter driver 2 Any ideas why libvirtd isn't starting? -- ---------- If you want to send stuff to the bit bucket, email Phineas.Ferb(a)Kandre.com .

1 0

[libvirt-users] virt-manager/libvirt backwards compatibility problem?
by Whit Blauvelt 12 Jul '11

12 Jul '11

Hi, Wanting to test some recent features of libvirt, I installed 0.9.3 on a couple of systems. It works fine on those, but since upgrading neither of them can successfully connect with virt-manager or virsh to a couple of other systems running libvirt 0.8.3. Even after upgrading virt-manager and virtinst to the latest versions on the 0.9.3 systems, they fail like this in virt-manager: Unable to open a connection to the libvirt management daemon. Libvirt URI is: qemu+ssh://root@192.168.1.67/system Verify that: - The 'libvirtd' daemon has been started Cannot recv data: : Connection reset by peer Traceback (most recent call last): File "/usr/src/virt-manager-0.8.7/src/virtManager/connection.py", line 1055, in _try_open None], flags) File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 102, in openAuth if ret is None:raise libvirtError('virConnectOpenAuth() failed') libvirtError: Cannot recv data: : Connection reset by peer Virsh simple fails with: error: Cannot recv data: : Connection reset by peer error: failed to connect to the hypervisor Since it's certain that the libvirtd daemon has been started on the other systems (they have production VMs that are running), this leaves me puzzled. This connection for virt-manager worked flawlessly for months when all the systems had libvirt 0.8.3. Is this a known incompatibility? Something I have to tweak somewhere? Thanks, Whit

1 2

[libvirt-users] Compatibility with Parallels Virtouzo
by Andreas Mauf 12 Jul '11

12 Jul '11

Hi, will libvirt work with the commercial parallels virtuozzo, too? Cause the linux version of virtuozzo is based on openvz, which ist supported by libvirt. Does someone have some experencies with that? Thanks for any feedback, Andreas -- SysEleven GmbH Rosenthaler Str. 34/35 10178 Berlin Firmensitz: Berlin Registergericht: AG Berlin Charlottenburg, HRB 108571 B Geschäftsführer: Marc Korthaus

2 7

[libvirt-users] ANNOUNCE: libvirt Perl bindings Sys::Virt 0.9.2 release
by Daniel P. Berrange 11 Jul '11

11 Jul '11

I am happy to announce a new release[1] of the libvirt Perl bindings, Sys::Virt 0.9.2 is available for download: http://search.cpan.org/CPAN/authors/id/D/DA/DANBERR/Sys-Virt-0.9.2.tar.gz Changes in this release - Changed version numbering to track the corresponding minimum required libvirt releases - Add all new APIs in libvirt 0.9.2 - Requires libvirt >= 0.9.2 The permanent link for the Sys::Virt package, where all historic releases can be found, is http://search.cpan.org/dist/Sys-Virt/ Thanks to everyone who contributed to this release through testing, bug reporting, patch submission, etc Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 0

[libvirt-users] Questions on libvirt hook scripts
by Whit Blauvelt 11 Jul '11

11 Jul '11

Hi, Reading http://libvirt.org/hooks.html I'm wondering of the following implication is accurate: Under "QEMU guest migration" it says At the beginning of the migration, the qemu hook script on the _destination_ host is executed with the "start" operation. Above that, under "Specifics" Before a QEMU guest is started, the qemu hook script is called in two locations; if either location fails, the guest is not started. The first location, since 0.9.0, is before libvirt performs any resource labeling.... This is called as: /etc/libvirt/hooks/qemu guest_name prepare begin - The second location, available Since 0.8.0, occurs after libvirt has finished labeling all resources, but has not yet started the guest, called as: /etc/libvirt/hooks/qemu guest_name start begin - Is it accurate that under 0.9.x, starting a VM will run the qemu hook script as both "prepare" and "start," but migrating a VM will only run the qemu hook script as "start"? Or is the description incomplete with libvirt also running "prepare" on migration? Another question, under "Calling libvirt functions from within a hook script" it says DO NOT DO THIS! A hook script must not call back into libvirt, as the libvirt daemon is already waiting for the script to exit. A deadlock is likely to occur. That makes obvious sense. But does it apply to calling libvirt on a second system? For example, a script might check the status of VMs on a second system as a condition of starting a VM on first, using virsh. My guess is that shouldn't deadlock. But then since during migration "the qemu hook script on the _destination_ host is executed," if the destination hook script were in turn to use virsh to check the _source_ host, then in a roundabout way a libvirt function has been called from within the hook script. I can't quite picture whether this particular instance would be dangerous. If it's accurate that the _destination_ hook script is only called with "start" and not with "prepare," the second question matters less. The checks on the second system that I want to do can be limited to the "prepare" invocation, and so never loop back. On the other hand, if the destination hook script _is_ called with "prepare" during migration, it would be useful to know how to tell if it's being called as part of a migration. TIA, Whit

1 0

[libvirt-users] NPIV + KVM
by Eric Ross 11 Jul '11

11 Jul '11

Is this possible: I would like to have a VM use a FC LUN exported to a virtual wwn (using NPIV) as its primary disk. I was thinking there might be a mechanism to say VM, boot using a LUN with this vwwn as your primary disk? Thanks in advance. -- --------------------------------------------------------------------- Eric Ross HPC Systems Administrator Argonne National Laboratory Leadership Computing Facility ---------------------------------------------------------------------

2 1

[libvirt-users] Creating a CENTOS VM
by Dale Amon 11 Jul '11

11 Jul '11

I used the following command: virt-install --connect qemu:///system -n server -r 512 --vcpus=1 -f kvm/server.cyberteams.com/root.qcow2 -s 12 -c iso/CentOS-5.6-x86_64-bin-DVD-1of2.iso --vnc --noautoconsole --os-type linux --accelerate --network=bridge:br0 --hvm which with a BlueOnyx CD some months ago worked fine. However when I connected with virt-viewer, after going through the TEST function it then claimed it could not find the CD. Is CENTOS a bit strange in some way?

1 1

[libvirt-users] Changing path of VM configuration files
by Jatin Kumar 08 Jul '11

08 Jul '11

Hello, I am using shared storage and i want to keep all the configuration files of vms of different hosts in one single location (on shared storage). Is there a way i can change the default path=/etc/libvirt/qemu/<VMName>.xml to something else. I looked into libvirtd.conf and qemu.conf but could not find any such thing. -- Jatin

3 2

[libvirt-users] KVM and <interface type='ethernet'>
by Maximilian Wilhelm 07 Jul '11

07 Jul '11

Hi! I'm trying to set up a VM with "just an tap device" with the following config (basicly inherited from 'virsh domxml-from-native qemu-argv'): <domain type='kvm'> [...] <interface type='ethernet'> <mac address='52:54:1f:ac:08:51'/> <target dev='foo_eth0'/> <model type='virtio'/> </interface> [...] </devices> </domain> This sadly failes with: | error: Failed to start domain foo | error: internal error process exited while connecting to monitor: could not configure /dev/net/tun: Device or resource busy I'm wondering why this fails as there shouldn't anything be done with the tap device besides setting it up. (The basic goal would be to set up a VM with a tap device, put an v4 and v6 IP on it and let OSPF do the rest. As the <script> parameter will not work with dropped privileges I wrote a wrapper for the kvm binary which takes care of this via sudo. This part works, but I fail to get the VM started with <interface type='ethernet'>) Any ideas? Thanks Max -- <@uschebit> Das erklärt die Sitte. Das ist so ähnlich wie mit dem Verbeugen zur Begrüßung in Japan. Das dient auch nur dazu, durch Begutachten der Schuhqualität den sozialen Rang festzustellen.

1 0

[libvirt-users] Is arping useful if a VM is brought up on a different (bridged) interface/machine?
by Whit Blauvelt 07 Jul '11

07 Jul '11

Hi, Using libvirt/qemu/kvm VMs, if a VM has stopped on one host and then the identical VM is started afresh on a different host, with the exact same (bridged) VM IP, would there be a point in having the VM run arping (or arping2) on startup to help it be quickly found on the LAN? Or is this built in at some level already? Or does it not apply here? Thanks, Whit

1 0