- Devel - libvirt List Archives

[libvirt] [ANNOUNCE] New release virt-manager 0.7.0
by Cole Robinson 10 Mar '09

10 Mar '09

I'm happy to announce a new virt-manager release, version 0.7.0. The release can be downloaded from: http://virt-manager.org/download.html The direct download link is: http://virt-manager.org/download/sources/virt-manager/virt-manager-0.7.0.ta… This release includes: - Redesigned 'New Virtual Machine' wizard (Jeremy Perry, Tim Allen, Cole Robinson) - Option to remove storage when deleting a virtual machine. - File browser for libvirt storage pools and volumes, for use when attaching storage to a new or existing guest. - Physical device assignment (PCI, USB) for existing virtual machines. - Bug fixes and minor improvements. Thanks to everyone who has contributed to this release through testing, bug reporting, submitting patches, and otherwise sending in feedback! Thanks, Cole

1 0

[libvirt] Re: [et-mgmt-tools] latest virt-manager and virtinst on centos-5
by Cole Robinson 10 Mar '09

10 Mar '09

Farkas Levente wrote: > hi, > the these packages: > virt-manager-0.6.1-4 > python-virtinst-0.400.2-3 > libvirt-python-0.6.1-1 > libvirt-0.6.1-1 > on centos-5 gives this error when i try to install a new guest after > press finish in virt manager: > -------------------------------------------- > Unable to complete install 'libvirt.libvirtError internal error unable > to start guest: > Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/create.py", line 717, in > do_install > dom = guest.start_install(False, meter = meter) > File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 536, > in start_install > return self._do_install(consolecb, meter, removeOld, wait) > File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 628, > in _do_install > self.domain = self.conn.createLinux(install_xml, 0) > File "/usr/lib64/python2.4/site-packages/libvirt.py", line 973, in > createLinux > if ret is None:raise libvirtError('virDomainCreateLinux() failed', > conn=self) > libvirtError: internal error unable to start guest: > ' This was a libvirt bug that should have been fixed in the latest release. Could be some other variant of it since you are running centos. - Cole

1 0

[libvirt] libvirt 0.6.1 not playing well with RHEL5.2 lokkit
by Charles Duffy 09 Mar '09

09 Mar '09

Howdy. I'm running RHEL5.2, and libvirt 0.6.1. I don't use the distro-provided firewall (system-config-securitylevel-tui-1.6.29.1-2.1.el5) and have it completely disabled, but libvirt appears to be having some trouble ascertaining as much: > libvirtd: 14:05:42.807: warning : Failed to read /etc/sysconfig/system-config-firewall > last message repeated 2 times > kernel: fvtebr0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature. > kernel: fvtebr0: starting userspace STP failed, starting kernel STP > libvirtd: 14:06:34.825: error : internal error '/usr/sbin/lokkit --nostart --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/INPUT.chain' exited with non-zero status 1 and signal 0: --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/INPUT.chain: unknown option > libvirtd: 14:06:34.825: warning : Failed to run '/usr/sbin/lokkit --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/INPUT.chain': Invalid argument > libvirtd: 14:06:34.828: error : internal error '/usr/sbin/lokkit --nostart --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/FORWARD.chain' exited with non-zero status 1 and signal 0: --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/FORWARD.chain: unknown option > libvirtd: 14:06:34.828: warning : Failed to run '/usr/sbin/lokkit --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/FORWARD.chain': Invalid argument > libvirtd: 14:06:34.831: error : internal error '/usr/sbin/lokkit --nostart --custom-rules=ipv4:nat:/var/lib/libvirt/iptables/nat/POSTROUTING.chain' exited with non-zero status 1 and signal 0: --custom-rules=ipv4:nat:/var/lib/libvirt/iptables/nat/POSTROUTING.chain: unknown option > libvirtd: 14:06:34.831: warning : Failed to run '/usr/sbin/lokkit --custom-rules=ipv4:nat:/var/lib/libvirt/iptables/nat/POSTROUTING.chain': Invalid argument

2 1

[Fwd: Re: [libvirt] Libvirt audio xml format]
by Simon Lambourn 09 Mar '09

09 Mar '09

1 0

[libvirt] FileSystem Creation for Logical Storage Volume
by Martin Gajdos 09 Mar '09

09 Mar '09

Hi there As I haven't found this information anywhere else, I'm trying this mailing list. I would like to know if it's possible to create a filesystem (ext3 for e.g.) along with a storage volume with libvirt. The volumes are located on a remote system. So is there function in libvirt for this? and if not, what would be the way to go? Thanks Martin Gajdos

1 0

[libvirt] Libvirt audio xml format
by Simon Lambourn 08 Mar '09

08 Mar '09

Hi, excuse the possible dumb question from a new KVM/Libvirt user - I'm very impressed overall but struggling to work out how to define an audio device in the libvirt xml. I have a virtualised windows XP up & running, now want to add an audio device. I can see how to do it in kvm and I believe audio devices are now supported in libvirt, but could not find documentation on how to write the xml. System is Ubuntu 8.10 on AMD64. Thanks in anticipation.

2 1

[libvirt] lxc: dominfo.cpuTime support using cgroups.cpuacct
by Ryota Ozaki 06 Mar '09

06 Mar '09

Hi, This patch enables to get CPU usage of a lxc using cpuacct subsystem of cgroups. Thanks, ozaki-r

3 7

[libvirt] PATCH: Fix crash after deleting storage vol fails
by Daniel P. Berrange 06 Mar '09

06 Mar '09

After a little debugging on IRC we discovered a problem in the deletion of storage volumes. We were mistakenly calling virStorageVolFree(vol) even if the delete call failed. So the pool got left with a NULL storage volume, and later use of that pool could crash on this. Daniel Index: src/storage_driver.c =================================================================== RCS file: /data/cvs/libvirt/src/storage_driver.c,v retrieving revision 1.32 diff -u -p -r1.32 storage_driver.c --- src/storage_driver.c 5 Feb 2009 16:28:30 -0000 1.32 +++ src/storage_driver.c 6 Mar 2009 12:56:20 -0000 @@ -1296,7 +1296,6 @@ storageVolumeDelete(virStorageVolPtr obj ret = 0; cleanup: - virStorageVolDefFree(vol); if (pool) virStoragePoolObjUnlock(pool); return ret; -- |: 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 :|

3 2

[libvirt] Questions on "Xen XM error : internal error unable to store config file handle"
by Taeho Kang 06 Mar '09

06 Mar '09

Dear all, I am trying to add defined domains to a hypervisor with virDomainDefineXML function. But I keep getting the following error. libvir: Xen XM error : internal error unable to store config file handle I tried using virsh, but it gave the same error. Does anybody know the cause of this error? Thank you in advance, /Taeho

2 1

[libvirt] [RFC]: Secure migration
by Chris Lalancette 05 Mar '09

05 Mar '09

All, I've been looking at implementing secure migration for libvirt. I've taken a look at two approaches; I'll outline them, and then tell you which one I think we should do, and why. Note that in the discussion below, I'm talking mostly about the qemu migration protocol; I believe both of the approaches will lend themselves to, say, Xen, but the details will be different. For the sake of the outlines, I'm using three specific terms: "src" is used to refer to the source of the migration, that is, where the VM is running *before* migration begins; "dst" is used to refer to the destination of the migration, that is, where we want the VM to be at the end; and "controller" refers to the controlling program (usually virsh), which can be run on an entirely separate machine. -------------------------------------------------------------------------------- 1) virsh on the controller connects to the src, and initiates the migration command. In turn, this causes the controller to also connect to the dst. Now, during the "Prepare" step on the dst, we setup a qemu container to listen to some port on localhost. Next, the "Perform" step is called on the src machine. This causes an external program to be forked on the src; this external program connects to the dst (using virConnectOpen), then waits for migration data from the qemu instance. As the migration data comes in, it uses a new RPC call (something like "writeMigrationData") to pass the data to the dst. The dst then takes that data, and writes it out to the waiting qemu container. Pros: Uses existing RPC mechanism, so you don't have to open a new port on the destination Cons: There is a "hidden" dependency between the src and dst, which may be difficult for users to get right (more on this below). 2) virsh on the controller connects to the src, and initiates the migration command. In turn, this causes the controller to also connect to the dst. Now, during the "Prepare" step on the dst, we setup a qemu container to listen to some port (call it 1234) on localhost. It also forks an external program (or a thread) to listen for an incoming gnutls connection. Next, the "Perform" step is call on the src machine. This forks an external program (or thread) to listen for incoming data from a localhost migration, do the gnutls handshake with the dst, and dump the data over the gnutls connection to the dst. Pros: Works mostly transparently; the user doesn't have to set anything up different than they do today for "unsecure" migration Cons: Requires opening a new (but still well-known) port in the firewall on the dst side. -------------------------------------------------------------------------------- More about the "hidden" dependencies for 1). There are quite a few examples of where the controller might have access to both machines, but the src libvirtd does not. A few examples below: a) libvirtd is using TLS + the "tls_allowed_dn_list" in /etc/libvirt/libvirtd.conf on the dst machine. They have it configured so that they can access the machine via TLS on the controller machine, but not from the src machine. b) libvirtd is using SASL digest-md5 on the dst machine. When the src machine tries to connect, it needs a name and password to do so, which it doesn't have. (technically, I guess we could proxy that response back to the controller, and have the user fill it there, and then return back to the src, and then the dst, but it seems roundabout) c) libvirtd is using SASL gssapi on the dst machine. When the src machine tries to connect to the dst, it needs to have the right configuration (i.e. /etc/krb5.conf and /etc/sasl2/libvirt.conf need to work), and it also has to get some kind of principal from the kerberos server (but which principal?). Because of the hidden dependency problem, I think solution 2) is actually more viable; yes, it also has a dependency (opening a hole in the firewall), but that can be documented and will work no matter what other authentication you are doing between the controller and src and dst machines. However, I am open to being convinced otherwise. Thoughts? -- Chris Lalancette

4 8