- Devel - libvirt List Archives

[Libvir] Register libvirtd ports with IANA ?
by Daniel P. Berrange 18 Jun '07

18 Jun '07

For the libvirtd we currently use two ports 16509 - TCP unencrypted stream 16514 - TLS encrypted stream My first thought is that we should really use consequetive port numbers eg 16510 and 16511. Second, we should register our port numbers with IANA http://www.iana.org/protocols/forms.htm Thoughts ? Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 7

[Libvir] PATCH: Fix marshalling of ID on wire with remote
by Daniel P. Berrange 18 Jun '07

18 Jun '07

THe code which marshalls virDomainptr objects onto the wire in the remote driver forgets to include the 'id' value. We get away with this for Xen and QEMU because they do most things based off name or UUID. The test driver however wants the ID number. The attached patch fixes this Dan -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] [PATCH] setmem checks
by Mark Johnson 18 Jun '07

18 Jun '07

This one may be a little contentious... This patch does a couple of things... It won't let you set memory if the value is greater that maxmem. It also will lower memory if max memory is set to less than memory. I think it's a good argument that this checking should be in the hypervisor control daemon. IMO, it should be both here and in the daemon. I have no idea why the patch diff is so big, Below is the diff after it is applied. A little easier to read. Mark [root@fedora libvirt]# diff src/virsh.orig src/virsh.c 1664a1665 > virDomainInfo info; 1673a1675,1677 > if (virDomainGetInfo(dom, &info) != 0) { > info.maxMem = 0; > } 1675c1679 < if (kilobytes <= 0) { --- > if ((kilobytes <= 0) || (kilobytes > info.maxMem)) { 1708a1713 > virDomainInfo info; 1723a1729,1737 > if (virDomainGetInfo(dom, &info) != 0) { > info.memory = 0x7fffffff; > } > > if (kilobytes < info.memory) { > if (virDomainSetMemory(dom, kilobytes) != 0) { > return FALSE; > } > } [root@fedora libvirt]#

5 12

[Libvir] [PATCH] header file changes for Solaris
by Mark Johnson 16 Jun '07

16 Jun '07

This patch has the includes need to build on Solaris. I've been using ifdef linux & ifndef linux to distinguish between solaris and linux at this point. I'm not sure what the preference is... MRJ

5 20

[Libvir] virt-manager bug
by Mark Johnson 16 Jun '07

16 Jun '07

Not sure if this is the right alias... This fixes virt-manager -c test:///default : p5b-vm[1]#; diff /tmp/connection.orig /usr/share/virt-manager/virtManager/connection.py 194,195d193 > else: > return self.get_type() + ":" + self.get_hostname() def get_name(self): if self.get_type()[0:3] == "Xen": return "Xen: " + self.get_hostname() elif self.get_type() == "QEMU": if self.uri == "qemu:///session": return "QEMU session: " + self.get_hostname() else: return "QEMU system: " + self.get_hostname() else: return self.get_type() + ":" + self.get_hostname()

2 1

[Libvir] patch status
by Mark Johnson 16 Jun '07

16 Jun '07

Ok, just a quick check so I can get my head on straight... :-) This patch was withdrawn.. [PATCH] return 0 networks if Network driver not implemented These patches have been applied [PATCH] Spelling fix [PATCH] null pointer fix on debug build [PATCH] setvcpus message [PATCH] vcpuinfo message [PATCH] _N() has a conflict in Solaris This patch looks like it's about to be applied (with some addition changes from Rich) [PATCH] header file changes for Solaris And these three are still being hashed out. [PATCH] setmem checks [PATCH] hypervisor version [PATCH] Solaris dom0 support Mark

2 1

[Libvir] [PATCH] Solaris dom0 support
by Mark Johnson 16 Jun '07

16 Jun '07

This is a little bigger of a patch. It has a couple of things in it. First, in xen_internal.c and xs_internal.c have general dom0 support for Solaris. Again, using #ifdef/ifndef __linux__ to separate the logic. In xml.c and xend_internal.c, the code which requires kernel to be defined if ifdef __linux__'d. For our setup, If bootloader, kernel, and ramdisk aren't defined, pygrub will got looking for the right bits. There also code which puts in the the vncpasswd in xend_internal.c. This is the last patch I'll send out for today... Mark

5 15

[Libvir] libvirt ./configure
by Mark Johnson 16 Jun '07

16 Jun '07

Just thought I'd throw a note to you.. I notice that if I do a configure on fedora7 as a user I get the following... checking If XenD UNIX socket /var/run/xend/xmlrpc.sock is accessible... no Which works when you do a configure as root. Not sure what your using that for so not sure if it's a problem.. Mark

2 1

[Libvir] Patch to get rid of index(3) and rindex(3)
by Richard W.M. Jones 15 Jun '07

15 Jun '07

According to index(3): [index and rindex appeared in] 4.3BSD; marked as LEGACY in POSIX.1-2001. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 3

[Libvir] Storage manager initial requirements and thoughts
by Hugh Brock 15 Jun '07

15 Jun '07

Hi all. At the Red Hat virtualization team meeting last week we spent some time talking about the problem of remote storage management, which is a requirement for at the very least creating remote guests. Remote storage management also delivers a lot of benefits for managing guest storage, provisioning, and a host of other issues. Note that we don't (I think) believe that storage management should be part of libvirt. However we might want to be able to grab storage information with libvirt when creating a guest, for example. Here's the tentative requirements we came up with, along with several questions that came up. We have two important use cases for remote storage management: --Create a new guest against an existing physical device --Create a new guest against a file on an existing physical device (SELinux context must match up on both) Requirements: 2 key requirements: enumerate devices, create files * Enumerate devices (unallocated disks) * storage pool * Unallocated space * Allocated volumes -- free -- in use * Read only / Read-write * Host availability * Volume -- Global unique name -- Local device name -- Usage -- Mounted locally -- Assigned to guest read only shared exclusive -- Inactive guest * Create a backing store for a guest * need to know what storage is available * Can be plain file * Can be a physical partition (local scsi/IDE, SAN) * Can be a logical volume * Can be network - iscsi/nbd Cases: Physical device --> create partitions Volume group --> create logical volumes Directory --> create files Todos: Investigate gparted, one of the partition management tools we already have (apis? remote accessibility?) (I believe Jim Meyering volunteered to take a look at this?) Identify what other scenarios we need to address. Please comment; I'm hoping we can get these into a more definite form sooner rather than later. -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock(a)redhat.com | virtualization library http://libvirt.org

10 43