- Devel - libvirt List Archives

[libvirt] Java JNA Patch series
by Bryan Kearney 28 Jul '09

28 Jul '09

Per the earlier email, here is the patch series

2 32

Re: [libvirt] VMware support and libcurl on rhel-u1
by Shahar Klein 28 Jul '09

28 Jul '09

apperantly I needed to unset CURLOPT_SSL_VERIFYHOST as well patched that and it is working now 10x Shahar ________________________________ From: Tom Hughes <tom(a)compton.nu> To: Shahar Klein <shaharklein(a)yahoo.com> Sent: Monday, July 27, 2009 2:36:32 PM Subject: Re: [libvirt] VMware support and libcurl on rhel-u1 On 27/07/09 12:33, Shahar Klein wrote: > this is what I thought but it doesn't work for me: > > [root@rain8 libvirt]# virsh -c esx://rain3?transport=http > Enter username for rain3 [root]: > Enter root password for rain3: > error: internal error curl_easy_perform() returned an error: SSL peer > certificate was not ok (51) > error: failed to connect to the hypervisor > > maybe because I'm using curl 7.15? That looks like it is still checking the certificate. Are you sure you're not still running the unpatched one somehow? I'm running curl 7.19.4 which isn't that different - does the curl_easy_setopt manual page mention the CURLOPT_SSL_VERIFYPEER option? Tom -- Tom Hughes (tom(a)compton.nu) http://www.compton.nu/

4 5

[libvirt] [PATCH 2/2] RPM spec file updated with glusterfs dependency
by Harshavardhana 28 Jul '09

28 Jul '09

Add new dependency for glusterfs rpm. --- libvirt.spec.in | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 1e8a8ef..ccef3a5 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -86,6 +86,8 @@ BuildRequires: util-linux # For showmount in FS driver (netfs discovery) BuildRequires: nfs-utils Requires: nfs-utils +# For glusterfs +Requires: glusterfs-client >= 2.0.2 %endif %if %{with_qemu} # From QEMU RPMs -- 1.6.0.6

4 6

[libvirt] [RFC/Experimental]: Tunnelled migration
by Chris Lalancette 28 Jul '09

28 Jul '09

All, Attached is the current version of the tunnelled migration patch, based upon danpb's generic datastream work. In order to use this work, you must first grab danpb's data-streams git branch here: http://gitorious.org/~berrange/libvirt/staging and then apply this patch on top. In some basic testing, this seems to work fine for me, although I have not given it a difficult scenario nor measured CPU utilization with these patches in place. DanB, these patches take a slightly different approach than you and I discussed yesterday on IRC. Just to recap, you suggested a new version of virMigratePrepare (called virMigratePrepareTunnel) that would take in as one of the arguments a datastream, and during the prepare step properly setup the datastream. Unless I'm missing something (which is entirely possible), this would also require passing that same datastream into the perform and finish stages, meaning that I'd essentially have an all new migration protocol version 3. To try to avoid that, during the prepare I store the port that we used to start the listening qemu in a new field in the virDomainObj structure. Then during the perform step, I create a datastream on the destination and run a new RPC function called virDomainMigratePrepareTunnel. This looks that port back up, associates it with the current stream, and returns back to the caller. Then the source side just does virStreamSend for all the data, and we have tunnelled migration. TODO: - More testing, especially under worst-case scenarios (VM constantly changing it's memory during migration) - CPU utilization testing to make sure that we aren't using a lot of CPU time doing this - Wall-clock testing - Switch over to using Unix Domain Sockets instead of localhost TCP migration. With a patch I put into upstream qemu (and is now in F-12), we can totally get rid of the scanning of localhost ports to find a free one, and just use Unix Domain Sockets. That should make the whole thing more robust. -- Chris Lalancette

2 2

[libvirt] test driver and virtOpenAuth()
by Bryan Kearney 28 Jul '09

28 Jul '09

I am trying to test a call into virConnectOpenAuth. How can I configure the test driver to accept auth calls on "test+tcp://localhost/default" Thanks! -- bk

2 4

[libvirt] [RFC] secrets API, was Re: [PATCH 0/9] Add support for (qcow*) volume encryption
by Miloslav Trmac 28 Jul '09

28 Jul '09

Hello, based on your comments, here is a proposal for a "secret management" API. Rather than add explicit accessors for attributes of secrets, and hard-code the "secrets are related to storage volumes" association in the API, the proposed uses XML to manipulate the association as well as other attributes, like it is used in other areas of libvirt. The user would allocate an ID for the secret using virSecretAllocateID(), set attributes of the secret using XML, e.g. <secret ephemeral='no' private='yes'> <volume>/var/lib/libvirt/images/mail.img</volume> <description>LUKS passphrase for the main hard drive of our mail server</description> </secret> Then, the secret value can be either generated and stored by libvirt, or supplied by the user using virSecretSetValue(). A simple API is provided for enumeration of all secrets. Very large deployments manage secret IDs automatically, so it probably is not necessary to provide specialized lookup functions (e.g. allowing the volume key -> secret ID lookup in less than O(number of secrets)). The <encryption> element used in volume and domain specifications remains, but it never contains any secrets directly, only something like <secret type='passphrase' secret_id='c1f11a6d-8c5d-4a3e-ac7a-4e171c5e0d4a' /> More detailed documentation is in the patch. Does that look OK? Thank you, Mirek

1 0

Re: [libvirt] [PATCH 0/9] Add support for (qcow*) volume encryption
by Miloslav Trmac 28 Jul '09

28 Jul '09

Hello, ----- "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > On Fri, Jul 24, 2009 at 07:25:54AM -0400, Miloslav Trmac wrote: > > A client in this case is the central, fully trusted, management > > system (e.g. oVirt), there is no need to protect against it. > > A more likely flow is > > > > MGMT client (no knowledge of secrets) > > | > > v > > MGMT server + key server (integrated or separate but cooperating) > > | > > v > > libvirt daemon > > | > > v > > qemu > > > > > What I am suggesting is that libvirt daemon should communicate > > > with the key server directly in all cases, and take the client > > > out of the loop. The client should merely indicate whether it > > > wants encryption or not, and never be able to directly access > > > any key material itself. With a direct trust relationship > > > between the key server and each libvirtd daemon, you do now > > > have a guarentee that keys are only ever used on the node for > > > which they are intended. You also have the additional guarentee > > > that no libvirt client can ever see any key secrets or passphrases > > > since it has been taken completely out of the loop. > > > > As far as I understand it, the whole point of virtual machine > > encryption is that the nodes are _not_ trusted, and different > > encryption keys protect data on different nodes. > > I did not mean to imply that libvirtd on a node should have > access to *all* secrets. Each libvirtd daemon has its own > identity, and when talking to a keys server it would authenticate > and the key server would only allow it access to some sub-set > of keys. ie, only the keys neccessary for VMs it needs to run. <snip> > If you have each libvirtd requesting secrets directly from the > keystore, at the time it starts a guest, then should an admin > issue a migrate command manually, the destination libvirtd > would still be unable to access the secrets of the incoming > VM, since the keystore will not have been configured to allow > it access. > > We also have to bear in mind how the MGMT server communicates > with the libvirt daemon. One likely option is using a messaging > service, which offers authenticity but not secrecy. ie, libvirt > receiving a request off the message bus can be sure the request > came from the mgmtm server, but cannot be sure it wasn't seen > by other users during transport. Thus by including secrets in > the XML, you could be exposing them to the message bus adminstrator. Is this likely to happen? No such transport is currently implemented AFAICS, and just using TLS is much simpler - it is already implemented, and gives you authentication of both sides almost for free. Why would such a messaging service be necessary for the client<->libvirtd connection, but not the libvirtd<->key server connection? > Taking your diagram, I think I would generalize it still further > to allow for mgmt server to be optional separate from key server, > and to introduce a "message bus" between MGMT server & libvirt. > Really pushing the limits of ASCII art... > > MGMT client > | > V > MGMT server <---> Key server > | ^ > V | > message bus | > | | > V | > libvirt daemon <----/ > | > V > QEMU This makes sense if you do not want to store any secrets locally at the node at any cost, but the strong coupling of the libvirtd daemon and the key server is a significant disadvantage: not only would the key server and libvirtd both have to implement the same protocol for transferring secrets, but the MGMT server, key server and libvirtd would all have to share the same concept of "identity" and the same method of authentication - and the MGMT server would have to manipulate the libvirt accounts on the key server. There are a few products that offer a company-wide key server, but there AFAIK is no standardized protocol for transferring the secrets yet (the KMIP committee was formed only a few months ago), and not even a proposal for any account management on the key server. We don't know what the industry standard will look like - or whether there will be any; right now, any key server used in connection with libvirt-managed nodes would have to implement a libvirt-specified interface (in addition to any interface it may provide to other clients). It is much simpler to use the already implemented libvirt remote interface, and give the MGMT server implementors a free hand in deciding which key server, if any, they will use, and to avoid the non-trivial effort of specifying the specialized libvirtd<->key server protocol and implementing both ends of it. If secrets related to auto-start domains are stored locally on the node, all secrets needed by libvirtd will be anticipated by the MGMT server, who can provide them before starting the operation. This makes the libvirtd->key server connection unnecessary. The API proposal that will follow adds a secret management interface to libvirtd. The API allows libvirtd to use a persistent local secret store, as well as an external key server as described above. In addition, it also allows a "fully managed" mode, where the storage and provision of secrets is the responsibility of the MGMT server. This is accomplished by giving each secret two attributes: "private", which prohibits libvirtd from divulging the secret to any client (this was done in the previous implementation in XML, but now that secrets are out-of-bound, making secrets private does not break any round-trip XML editing), and "ephemeral", which prohibits libvirt from storing the secret persistently. The MGMT server would send the necessary secrets before any operation that needs them, and delete them from the node when they are no longer necessary. Looking at your use cases: > - A node can only see secrets for VMs it is configured to run Same in "fully managed" mode. > - MGMT server does not need to ever see the secrets itself. It > merely controls access for which nodes can see them, and can > request generation of new secrets The MGMT server needs to see the secrets in "fully managed mode". The MGMT server can actually see them even if libvirtd talks to the key server directly, because the key server is allowed to manipulate permissions of the secrets and it can give itself the permission to read them. The MGMT server can also delete any interface, or boot a "rescue image" that copies the plaintext out of the virtual machine. The MGMT server must be trusted in any case. > - Messages between the MGMT server & libvirtd do not need to > be encrypted, since they don't include secrets I can't see why this is useful - the connection will use TLS anyway. > - Other users who authenticate to libvirt on a node cannot > move a VM to an unauthorized node, since it can't see secrets Same in "fully managed" mode. > - VM save memory images (which include the fully XML) do not ever > expose the secrets. So VM save image cannot be restored on an > unauthorized node. Same in "fully managed" mode. Mirek

1 0

[libvirt] VMware ESX: Add no_verify query parameter
by Matthias Bolte 27 Jul '09

27 Jul '09

Adds a no_verify query parameter to stop libcurl from verifying the server certificate for the https transport. Idea from Tom Hughes. Regards, Matthias

3 2

[libvirt] PATCH: Implement vCPU cpuTime + cpu fields for QEMU
by Daniel P. Berrange 27 Jul '09

27 Jul '09

The qemudDomainGetVcpus() method in QEMU driver has the following long standing todo item /* XXX cpu time, current pCPU mapping */ This has caused confusion for users, because they set affinity and then wonder why 'virsh vcpuinfo' constantly reports their guest as running on pCPU 0. This patch implements the missing bits, pulling it out of /proc/$PID/task/$TID/stat ie, the per-vCPU thread status file Daniel diff --git a/src/qemu_driver.c b/src/qemu_driver.c index c594495..388843f 100644 --- a/src/qemu_driver.c +++ b/src/qemu_driver.c @@ -2465,24 +2465,44 @@ cleanup: } -static int qemudGetProcessInfo(unsigned long long *cpuTime, int pid) { +static int qemudGetProcessInfo(unsigned long long *cpuTime, int *lastCpu, int pid, int tid) { char proc[PATH_MAX]; FILE *pidinfo; unsigned long long usertime, systime; + int cpu; + int ret; - if (snprintf(proc, sizeof(proc), "/proc/%d/stat", pid) >= (int)sizeof(proc)) { + if (tid) + ret = snprintf(proc, sizeof(proc), "/proc/%d/task/%d/stat", pid, tid); + else + ret = snprintf(proc, sizeof(proc), "/proc/%d/stat", pid); + if (ret >= (int)sizeof(proc)) { + errno = E2BIG; return -1; } if (!(pidinfo = fopen(proc, "r"))) { /*printf("cannot read pid info");*/ /* VM probably shut down, so fake 0 */ - *cpuTime = 0; + if (cpuTime) + *cpuTime = 0; + if (lastCpu) + *lastCpu = 0; return 0; } - if (fscanf(pidinfo, "%*d %*s %*c %*d %*d %*d %*d %*d %*u %*u %*u %*u %*u %llu %llu", &usertime, &systime) != 2) { - qemudDebug("not enough arg"); + /* See 'man proc' for information about what all these fields are. We're + * only interested in a very few of them */ + if (fscanf(pidinfo, + /* pid -> stime */ + "%*d %*s %*c %*d %*d %*d %*d %*d %*u %*u %*u %*u %*u %llu %llu" + /* cutime -> endcode */ + "%*d %*d %*d %*d %*d %*u %*u %*d %*u %*u %*u %*u" + /* startstack -> processor */ + "%*u %*u %*u %*u %*u %*u %*u %*u %*u %*u %*d %d", + &usertime, &systime, &cpu) != 3) { + VIR_WARN0("cannot parse process status data"); + errno = -EINVAL; return -1; } @@ -2491,9 +2511,14 @@ static int qemudGetProcessInfo(unsigned long long *cpuTime, int pid) { * _SC_CLK_TCK is jiffies per second * So calulate thus.... */ - *cpuTime = 1000ull * 1000ull * 1000ull * (usertime + systime) / (unsigned long long)sysconf(_SC_CLK_TCK); + if (cpuTime) + *cpuTime = 1000ull * 1000ull * 1000ull * (usertime + systime) / (unsigned long long)sysconf(_SC_CLK_TCK); + if (lastCpu) + *lastCpu = cpu; + - qemudDebug("Got %llu %llu %llu", usertime, systime, *cpuTime); + VIR_DEBUG("Got status for %d/%d user=%llu sys=%llu cpu=%d", + pid, tid, usertime, systime, cpu); fclose(pidinfo); @@ -3133,7 +3158,7 @@ static int qemudDomainGetInfo(virDomainPtr dom, if (!virDomainIsActive(vm)) { info->cpuTime = 0; } else { - if (qemudGetProcessInfo(&(info->cpuTime), vm->pid) < 0) { + if (qemudGetProcessInfo(&(info->cpuTime), NULL, vm->pid, 0) < 0) { qemudReportError(dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED, ("cannot read cputime for domain")); goto cleanup; } @@ -3676,7 +3701,16 @@ qemudDomainGetVcpus(virDomainPtr dom, for (i = 0 ; i < maxinfo ; i++) { info[i].number = i; info[i].state = VIR_VCPU_RUNNING; - /* XXX cpu time, current pCPU mapping */ + + if (vm->vcpupids != NULL && + qemudGetProcessInfo(&(info[i].cpuTime), + &(info[i].cpu), + vm->pid, + vm->vcpupids[i]) < 0) { + virReportSystemError(dom->conn, errno, "%s", + _("cannot get vCPU placement & pCPU time")); + goto cleanup; + } } } -- |: 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 :|

2 1

[libvirt] [PATCH] Canonicalize qemu machine types
by Mark McLoughlin 27 Jul '09

27 Jul '09

In qemu-0.11 there is a 'pc-0.10' machine type which allows you to run guests with a machine which is compatible with the pc machine in qemu-0.10 - e.g. using the original PCI class for virtio-blk and virtio-console and disabling MSI support in virtio-net. The idea here is that we don't want to surprise guests by changing the hardware when qemu is updated. I've just posted some patches for qemu-0.11 which allows libvirt to canonicalize the 'pc' machine alias to the latest machine version. This patches makes us use that so that when a guest is configured to use the 'pc' machine type, we resolve that to 'pc-0.11' machine and save that in the guest XML. See also: https://fedoraproject.org/wiki/Features/KVM_Stable_Guest_ABI * src/qemu_conf.c: add qemudCanonicalizeMachine() to parse the output of 'qemu -M ?' * src/qemu_driver.c: canonicalize the machine type in qemudDomainDefine() --- src/qemu_conf.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++++ src/qemu_conf.h | 3 + src/qemu_driver.c | 3 + 3 files changed, 120 insertions(+), 0 deletions(-) diff --git a/src/qemu_conf.c b/src/qemu_conf.c index 4043d70..3f4edfa 100644 --- a/src/qemu_conf.c +++ b/src/qemu_conf.c @@ -470,6 +470,120 @@ virCapsPtr qemudCapsInit(void) { return NULL; } +/* Format is: + * <machine> <desc> [(alias of <machine>)] + */ +static int +qemudParseMachineTypesStr(const char *machines ATTRIBUTE_UNUSED, + const char *machine ATTRIBUTE_UNUSED, + char **canonical) +{ + const char *p = machines; + + *canonical = NULL; + + do { + const char *eol; + char *s; + + if (!(eol = strchr(p, '\n'))) + return -1; /* eof file without finding @machine */ + + if (!STRPREFIX(p, machine)) { + p = eol + 1; + continue; /* doesn't match @machine */ + } + + p += strlen(machine); + + if (*p != ' ') { + p = eol + 1; + continue; /* not a complete match of @machine */ + } + + do { + p++; + } while (*p == ' '); + + p = strstr(p, "(alias of "); + if (!p || p > eol) + return 0; /* not an alias, name is canonical */ + + *canonical = strndup(p + strlen("(alias of "), eol - p); + + s = strchr(*canonical, ')'); + if (!s) { + VIR_FREE(*canonical); + *canonical = NULL; + return -1; /* output is screwed up */ + } + + *s = '\0'; + break; + } while (1); + + return 0; +} + +int +qemudCanonicalizeMachine(virConnectPtr conn ATTRIBUTE_UNUSED, + virDomainDefPtr def) +{ + const char *const qemuarg[] = { def->emulator, "-M", "?", NULL }; + const char *const qemuenv[] = { "LC_ALL=C", NULL }; + char *machines, *canonical; + enum { MAX_MACHINES_OUTPUT_SIZE = 1024*4 }; + pid_t child; + int newstdout = -1, len; + int ret = -1, status; + + if (virExec(NULL, qemuarg, qemuenv, NULL, + &child, -1, &newstdout, NULL, VIR_EXEC_CLEAR_CAPS) < 0) + return -1; + + len = virFileReadLimFD(newstdout, MAX_MACHINES_OUTPUT_SIZE, &machines); + if (len < 0) { + virReportSystemError(NULL, errno, "%s", + _("Unable to read 'qemu -M ?' output")); + goto cleanup; + } + + if (qemudParseMachineTypesStr(machines, def->os.machine, &canonical) < 0) + goto cleanup2; + + if (canonical) { + VIR_FREE(def->os.machine); + def->os.machine = canonical; + } + + ret = 0; + +cleanup2: + VIR_FREE(machines); +cleanup: + if (close(newstdout) < 0) + ret = -1; + +rewait: + if (waitpid(child, &status, 0) != child) { + if (errno == EINTR) + goto rewait; + + VIR_ERROR(_("Unexpected exit status from qemu %d pid %lu"), + WEXITSTATUS(status), (unsigned long)child); + ret = -1; + } + /* Check & log unexpected exit status, but don't fail, + * as there's really no need to throw an error if we did + * actually read a valid version number above */ + if (WEXITSTATUS(status) != 0) { + VIR_WARN(_("Unexpected exit status '%d', qemu probably failed"), + WEXITSTATUS(status)); + } + + return ret; +} + static unsigned int qemudComputeCmdFlags(const char *help, unsigned int version, unsigned int is_kvm, diff --git a/src/qemu_conf.h b/src/qemu_conf.h index fbf2ab9..b668669 100644 --- a/src/qemu_conf.h +++ b/src/qemu_conf.h @@ -123,6 +123,9 @@ int qemudExtractVersionInfo (const char *qemu, unsigned int *version, unsigned int *flags); +int qemudCanonicalizeMachine (virConnectPtr conn, + virDomainDefPtr def); + int qemudParseHelpStr (const char *str, unsigned int *flags, unsigned int *version, diff --git a/src/qemu_driver.c b/src/qemu_driver.c index d2db1a2..98f8e95 100644 --- a/src/qemu_driver.c +++ b/src/qemu_driver.c @@ -4102,6 +4102,9 @@ static virDomainPtr qemudDomainDefine(virConnectPtr conn, const char *xml) { } } + if (qemudCanonicalizeMachine(conn, def) < 0) + goto cleanup; + if (!(vm = virDomainAssignDef(conn, &driver->domains, def))) { -- 1.6.2.5

4 27

[libvirt] Unable to get libvirt working with KVM using direct kernel boot.
by Tiit Kaeeli 27 Jul '09

27 Jul '09

Hi, I am trying to get libvirt to manage a KVM virtual machine on Debian squeeze with multiple relevant parts included form unstable (because of need for gpt partition tables, Intel 82576 nic etc). Unfortunately the VM does not seem to boot. I will see a quemu prompt on /dev/pts/1. (Tried pressing c on it, but no difference). Nothing will appear on /dev/pts/2, /dev/pts/3 or when I type virsh console vm1_storage. If I grab the kvm command line generated by libvirt using ps and run it manually, it works fine. (Starts booting after I press c on /dev/pts/1 or remove the -S option from the command line) Libvirt configuration file: <domain type='kvm'> <name>vm1_storage</name> <uuid>29bfac01-b24d-e4ab-e741-f33f7e880d9d</uuid> <memory>4096000</memory> <currentMemory>4096000</currentMemory> <vcpu>6</vcpu> <os> <type>hvm</type> <kernel>/boot/vmlinuz-2.6.30-1-amd64</kernel> <initrd>/boot/initrd.img-2.6.30-1-amd64</initrd> <cmdline>"root=UUID=98d6d3d7-3782-4f6b-a94f-bc0272c0289d ro console=tty0 console=ttyS0,115200n8"</cmdline> </os> <features> <acpi/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/kvm</emulator> <disk type='block' device='disk'> <source dev='/dev/vm_lvm/vm01_storage_root'/> <target dev='vda' bus='virtio'/> </disk> <interface type='ethernet'> <mac address='52:54:00:12:34:56'/> <target dev='tap0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target port='0'/> </console> </devices> </domain> KVM command line that I see in ps after running virsh define /etc/libvirt/qemu/vm1_storage.xml virsh start vm1_storage (Works fine after I remove the -S option or press 'c' on quemu monitor on /dev/pts/1): /usr/bin/kvm -S -M pc -m 4000 -smp 6 -name vm1_storage -uuid 29bfac01-b24d-e4ab-e741-f33f7e880d9d -nographic -monitor pty -boot c -kernel /boot/vmlinuz-2.6.30-1-amd64 -initrd /boot/initrd.img-2.6.30-1-amd64 -append "root=UUID=98d6d3d7-3782-4f6b-a94f-bc0272c0289d ro console=tty0 console=ttyS0,115200n8" -drive file=/dev/vm_lvm/vm01_storage_root,if=virtio,index=0,boot=on -net nic,macaddr=52:54:00:12:34:56,vlan=0 -net tap,ifname=tap0,vlan=0 -serial pty -parallel none -usb /var/log/libvirt/qemu/vm1_storage.log shows: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/ /usr/bin/kvm -S -M pc -m 4000 -smp 6 -name vm1_storage -uuid 29bfac01-b24d-e4ab-e741-f33f7e880d9d -nographic -monitor pty -boot c -kernel /boot/vmlinuz-2.6.30-1-amd64 -initrd /boot/initrd.img-2.6.30-1-amd64 -append "root=UUID=98d6d3d7-3782-4f6b-a94f-bc0272c0289d ro console=tty0 console=ttyS0,115200n8" -drive file=/dev/vm_lvm/vm01_storage_root,if=virtio,index=0,boot=on -net nic,macaddr=52:54:00:12:34:56,vlan=0 -net tap,ifname=tap0,vlan=0 -serial pty -parallel none -usb char device redirected to /dev/pts/1 char device redirected to /dev/pts/2 qemu: loading initrd (0x76055b bytes) at 0x000000007f89f000 Versions in use: kvm 85+dfsg-4 libvirt0 0.6.5-2 libvirt-bin 0.6.5-2 linux-image-2.6.30-1-amd64 Thanks for any ideas.

2 1

[libvirt] VMware ESX: Allow leading dots in VMX config entry names
by Matthias Bolte 27 Jul '09

27 Jul '09

Hi, '.encoding = "UTF-8"' is a valid VMX config entry, so the virConfParser must accept it in VMX mode. This patch lets the parser accept those names with leading dots. Regards, Matthias

3 5

[libvirt] VMware ESX: Accept VI API version 4.0
by Matthias Bolte 27 Jul '09

27 Jul '09

Hi, This patch extends the VI API version checks to accept version 4.0 too. Regards, Matthias

2 2

[libvirt] VMware ESX: Fix memory leaks in esxDomainDumpXML()
by Matthias Bolte 27 Jul '09

27 Jul '09

Subject says it all.

2 1

[libvirt] Unable to get libvirt working with KVM using direct kernel boot.
by Tiit Kaeeli 27 Jul '09

27 Jul '09

Hi, I am trying to get libvirt to manage a KVM virtual machine on Debian squeeze with multiple relevant parts included form unstable (because of need for gpt partition tables, Intel 82576 nic etc). Unfortunately the VM does not seem to boot. I will see a quemu prompt on /dev/pts/1. (Tried pressing c on it, but no difference). Nothing will appear on /dev/pts/2, /dev/pts/3 or when I type virsh console vm1_storage. If I grab the kvm command line generated by libvirt using ps and run it manually, it works fine. (Starts booting after I press c on /dev/pts/1 or remove the -S option from the command line) Libvirt configuration file: <domain type='kvm'> <name>vm1_storage</name> <uuid>29bfac01-b24d-e4ab-e741-f33f7e880d9d</uuid> <memory>4096000</memory> <currentMemory>4096000</currentMemory> <vcpu>6</vcpu> <os> <type>hvm</type> <kernel>/boot/vmlinuz-2.6.30-1-amd64</kernel> <initrd>/boot/initrd.img-2.6.30-1-amd64</initrd> <cmdline>"root=UUID=98d6d3d7-3782-4f6b-a94f-bc0272c0289d ro console=tty0 console=ttyS0,115200n8"</cmdline> </os> <features> <acpi/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/kvm</emulator> <disk type='block' device='disk'> <source dev='/dev/vm_lvm/vm01_storage_root'/> <target dev='vda' bus='virtio'/> </disk> <interface type='ethernet'> <mac address='52:54:00:12:34:56'/> <target dev='tap0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target port='0'/> </console> </devices> </domain> KVM command line that I see in ps after running virsh define /etc/libvirt/qemu/vm1_storage.xml virsh start vm1_storage (Works fine after I remove the -S option or press 'c' on quemu monitor on /dev/pts/1): /usr/bin/kvm -S -M pc -m 4000 -smp 6 -name vm1_storage -uuid 29bfac01-b24d-e4ab-e741-f33f7e880d9d -nographic -monitor pty -boot c -kernel /boot/vmlinuz-2.6.30-1-amd64 -initrd /boot/initrd.img-2.6.30-1-amd64 -append "root=UUID=98d6d3d7-3782-4f6b-a94f-bc0272c0289d ro console=tty0 console=ttyS0,115200n8" -drive file=/dev/vm_lvm/vm01_storage_root,if=virtio,index=0,boot=on -net nic,macaddr=52:54:00:12:34:56,vlan=0 -net tap,ifname=tap0,vlan=0 -serial pty -parallel none -usb /var/log/libvirt/qemu/vm1_storage.log shows: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/ /usr/bin/kvm -S -M pc -m 4000 -smp 6 -name vm1_storage -uuid 29bfac01-b24d-e4ab-e741-f33f7e880d9d -nographic -monitor pty -boot c -kernel /boot/vmlinuz-2.6.30-1-amd64 -initrd /boot/initrd.img-2.6.30-1-amd64 -append "root=UUID=98d6d3d7-3782-4f6b-a94f-bc0272c0289d ro console=tty0 console=ttyS0,115200n8" -drive file=/dev/vm_lvm/vm01_storage_root,if=virtio,index=0,boot=on -net nic,macaddr=52:54:00:12:34:56,vlan=0 -net tap,ifname=tap0,vlan=0 -serial pty -parallel none -usb char device redirected to /dev/pts/1 char device redirected to /dev/pts/2 qemu: loading initrd (0x76055b bytes) at 0x000000007f89f000 Versions in use: kvm 85+dfsg-4 libvirt0 0.6.5-2 libvirt-bin 0.6.5-2 linux-image-2.6.30-1-amd64 Thanks for any ideas.

1 0

Re: [libvirt] VMware support and libcurl on rhel-u1
by Shahar Klein 27 Jul '09

27 Jul '09

I'll try with 7.15 can I test with ESX4i? Shahar ________________________________ From: Matthias Bolte <matthias.bolte(a)googlemail.com> To: Shahar Klein <shaharklein(a)yahoo.com> Sent: Sunday, July 26, 2009 5:56:18 PM Subject: Re: [libvirt] VMware support and libcurl on rhel-u1 2009/7/26 Shahar Klein <shaharklein(a)yahoo.com>: > It doesn't because I built libcurl on a different path (/usr/local/lib) > So I won't damage other stuff on this box. > I thought that this is what the LIBCURL_LIBS and LIBCURL_CFLAGS env vars are > for. No, but installing in the /usr/local prefix should also work with pkg-config. The .pc for libcurl should be located at /usr/local/lib/pkgconfig/libcurl.pc and pkg-config should find it. Maybe you have to set PKG_CONFIG_PATH in order to have pkg-config pick it up. Check the output of: pkg-config libcurl --modversion It should output 7.18 or what ever your version is, if installed correctly. > btw - Do I really need libcurl 7.18? trying to install it pushing me into > the depnendncy hell: [...] Hm... I just looked at the changelist of libcurl and something older like version 7.15 may also work, but I haven't tested it. You could give it a try and edit the configure.in file and change 7.18 to 7.15 and see if that works out. Regards, Matthias

3 10

[libvirt] [PATCH] Power Hypervisor support
by Eduardo Otubo 27 Jul '09

27 Jul '09

Hello everyone, This should be the official patch for the libvrt-0.7.0 release. Here I'll comment all the features already implemented and the roadmap we have ahead: Features supported: * Connects to HMC/VIOS or IVM systems. * Life cycle commands (resume and shutdown). * dumpxml * 'list' and 'list --all' What is being implemented: * better and centralized control for UUID * definexml * CPU management commands Any comment are always welcome. []'s -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems & Technology Group Mobile: +55 19 8135 0885 otubo(a)linux.vnet.ibm.com

3 5

[libvirt] [PATCH] test: Implement BlockStats and InterfaceStats
by Cole Robinson 27 Jul '09

27 Jul '09

We fake stats values based on the current time, similar to how it's done for cpu time. --- src/test.c | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 114 insertions(+), 2 deletions(-) diff --git a/src/test.c b/src/test.c index f02b58b..6db3825 100644 --- a/src/test.c +++ b/src/test.c @@ -2093,6 +2093,118 @@ cleanup: return ret; } +static int testDomainBlockStats(virDomainPtr domain, + const char *path, + struct _virDomainBlockStats *stats) +{ + testConnPtr privconn = domain->conn->privateData; + virDomainObjPtr privdom; + struct timeval tv; + unsigned long long statbase; + int i, found = 0, ret = -1; + + testDriverLock(privconn); + privdom = virDomainFindByName(&privconn->domains, + domain->name); + testDriverUnlock(privconn); + + if (privdom == NULL) { + testError(domain->conn, VIR_ERR_INVALID_ARG, __FUNCTION__); + goto error; + } + + for (i = 0 ; i < privdom->def->ndisks ; i++) { + if (STREQ(path, privdom->def->disks[i]->dst)) { + found = 1; + break; + } + } + + if (!found) { + testError(domain->conn, VIR_ERR_INVALID_ARG, + _("invalid path: %s"), path); + goto error; + } + + if (gettimeofday(&tv, NULL) < 0) { + virReportSystemError(domain->conn, errno, + "%s", _("getting time of day")); + goto error; + } + + /* No significance to these numbers, just enough to mix it up*/ + statbase = (tv.tv_sec * 1000UL * 1000UL) + tv.tv_usec; + stats->rd_req = statbase / 10; + stats->rd_bytes = statbase / 20; + stats->wr_req = statbase / 30; + stats->wr_bytes = statbase / 40; + stats->errs = tv.tv_sec / 2; + + ret = 0; +error: + if (privdom) + virDomainObjUnlock(privdom); + return ret; +} + +static int testDomainInterfaceStats(virDomainPtr domain, + const char *path, + struct _virDomainInterfaceStats *stats) +{ + testConnPtr privconn = domain->conn->privateData; + virDomainObjPtr privdom; + struct timeval tv; + unsigned long long statbase; + int i, found = 0, ret = -1; + + testDriverLock(privconn); + privdom = virDomainFindByName(&privconn->domains, + domain->name); + testDriverUnlock(privconn); + + if (privdom == NULL) { + testError(domain->conn, VIR_ERR_INVALID_ARG, __FUNCTION__); + goto error; + } + + for (i = 0 ; i < privdom->def->nnets ; i++) { + if (privdom->def->nets[i]->ifname && + STREQ (privdom->def->nets[i]->ifname, path)) { + ret = 0; + break; + } + } + + if (!found) { + testError(domain->conn, VIR_ERR_INVALID_ARG, + _("invalid path, '%s' is not a known interface"), path); + goto error; + } + + if (gettimeofday(&tv, NULL) < 0) { + virReportSystemError(domain->conn, errno, + "%s", _("getting time of day")); + goto error; + } + + /* No significance to these numbers, just enough to mix it up*/ + statbase = (tv.tv_sec * 1000UL * 1000UL) + tv.tv_usec; + stats->rx_bytes = statbase / 10; + stats->rx_packets = statbase / 100; + stats->rx_errs = tv.tv_sec / 1; + stats->rx_drop = tv.tv_sec / 2; + stats->tx_bytes = statbase / 20; + stats->tx_packets = statbase / 110; + stats->tx_errs = tv.tv_sec / 3; + stats->tx_drop = tv.tv_sec / 4; + + ret = 0; +error: + if (privdom) + virDomainObjUnlock(privdom); + return ret; +} + static virDrvOpenStatus testOpenNetwork(virConnectPtr conn, virConnectAuthPtr auth ATTRIBUTE_UNUSED, int flags ATTRIBUTE_UNUSED) { @@ -4117,8 +4229,8 @@ static virDriver testDriver = { NULL, /* domainMigratePrepare */ NULL, /* domainMigratePerform */ NULL, /* domainMigrateFinish */ - NULL, /* domainBlockStats */ - NULL, /* domainInterfaceStats */ + testDomainBlockStats, /* domainBlockStats */ + testDomainInterfaceStats, /* domainInterfaceStats */ NULL, /* domainBlockPeek */ NULL, /* domainMemoryPeek */ testNodeGetCellsFreeMemory, /* nodeGetCellsFreeMemory */ -- 1.6.0.6

2 3

[libvirt] VMware support and libcurl on rhel-u1
by Shahar Klein 26 Jul '09

26 Jul '09

I'm trying to play with the new ESX driver on a rhel5-u1 x86_64 but I get this: checking for libcurl libraries >= 7.18.0... configure: error: libcurl >= 7.18.0 is required for the ESX driver according to http://curl.haxx.se/download.html there is no rpm for rhel x86_64 so I built it and tried: export LIBCURL_LIBS="-L/usr/local/lib -lcurl -L/usr/kerberos/lib64" export LIBCURL_CFLAGS="-I/usr/local/include" but configure didn't care about it am I doing something wrong here? tnx Shahar Klein

2 1

[libvirt] How to get access to QEMU monitor?
by Jun Koi 26 Jul '09

26 Jul '09

Hi, I am running QEMU via libvirt (using virsh & virt-manager). Now I want to get access to the monitor interface of QEMU, so I can issue some commands to monitor. Is there anyway to do that? Thanks, J

2 1

[libvirt] VMware ESX driver progress
by Matthias Bolte 25 Jul '09

25 Jul '09

Hi, the development was hindered by our testing cluster being offline since 2 weeks due to server room cooling system maintenance. But I finally got a basic version of dump-XML done, that fills all fields of the virDomainDef that the VMX file contains data for. Changes since first announcement: - Move code into esx subdirectory - Add esxNodeGetInfo() - Fix esxDomainGetInfo() to report the correct value for memory - Add memory and max-memory getter/setters - Add CPU scheduler getter/setters - Validate a migration before trying to perform it - Replace esxUtil_Strdup() with strdup() and remove esxUtil_MigrateStringFromLibXML() - Add esxVI_EnsureSession() to handle expiring sessions - Separate VI client code into multiple files and generate most of the type handling code with macros - Add esxDomainDumpXML() based on esxVMX_ParseConfig() The ESX driver isn't complete yet, currently it supports: - domain lookup by ID, UUID and name - domain listing - domain info retrieval - domain suspend and resume - domain start and destroy - domain reboot and shutdown, if the VMware tools are installed inside the domain - domain migration with previous validation - domain memory configuration - domain CPU amount and scheduler configuration - domain XML-dump - domain XML-from-native (VMX) - node info retrieval - node hostname retrieval The next milestone is creating/defining a new domain from a domain XML config, but this will not be finished until feature freeze for 0.7.0 on friday. Regards, Matthias

3 9

[libvirt] [PATCH 1/1] Support for Callbacks and VirtualBox Version 3.
by Pritesh Kothari 24 Jul '09

24 Jul '09

Hi All, I have added support for callbacks and VirtualBox version 3. I have attached the patch for the same, it is made against the head as of today. To check if the callbacks work you can run the example from examples/domain- events/events-c directory and then start a domain to see if you get any callback events. Regards, Pritesh

3 4

Re: [libvirt] [PATCH 0/9] Add support for (qcow*) volume encryption
by Miloslav Trmac 24 Jul '09

24 Jul '09

----- "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > > Not quite: the main case of a "dumb" client would be a large-scale > > virtualization management software that contains a primary store > > of encryption information, and gives each node access only to those > > keys that are currently necessary by the node to run its domains; > > the fact that each node has access to only a limited set of keys > > prevents an attacker that compromises a single node from reading > > disk images of all domains managed in the entire site, even if > > the disk image storage (e.g. unencrypted NFS) does not allow > > managing access by each node separately. > > > > Such a client must be able to transfer the actual secrets, not only > > identifiers, to libvirt. (The idea of a "dumb" client, that does > > not know the specifics of the format, is an additional feature on > > top, but one that implies that the client does send the actual > secrets.) > > This implies a flow of secrets > > Key server --\ > +-> libvirt client -> libvirt daemon -> qemu > MGMT server --/ > > This does not in fact guarentee that secrets for a particular > node are only used on the node for which they are intended, > because the key server cannot be sure of what libvirt daemons > the libvirt client is connected to. A client in this case is the central, fully trusted, management system (e.g. oVirt), there is no need to protect against it. A more likely flow is MGMT client (no knowledge of secrets) | v MGMT server + key server (integrated or separate but cooperating) | v libvirt daemon | v qemu > What I am suggesting is that libvirt daemon should communicate > with the key server directly in all cases, and take the client > out of the loop. The client should merely indicate whether it > wants encryption or not, and never be able to directly access > any key material itself. With a direct trust relationship > between the key server and each libvirtd daemon, you do now > have a guarentee that keys are only ever used on the node for > which they are intended. You also have the additional guarentee > that no libvirt client can ever see any key secrets or passphrases > since it has been taken completely out of the loop. As far as I understand it, the whole point of virtual machine encryption is that the nodes are _not_ trusted, and different encryption keys protect data on different nodes. If all nodes are trusted, what additional functionality does volume encryption with per-volume keys provide? If the nodes are trusted to read only data from the domains they currently host, the nodes could just as well use an encrypted local hard drive to store all images, or share a single key to encrypt all images stored on a NFS/SAN. > Key server > | > V > MGMT server -> libvirt client -> libvirt daemon -> qemu > > > Storage of secrets in a separate keystore is more important for "local" > > libvirt deployments, where libvirt manages the primary, long-term, > > store of the secrets. > > Nope, I think that having a keystore for all scenarios is the > desirable end goal. Passing secrets around in the XML should > ideally never be done at all - we should aim to always have a > keystore that can be used. Secrets in the XML would just be a > fallback for a rarely used niche cases, or disaster recovery, > or experimentation. That means that any deployment of more than one node with migration requires a separate server providing a shared keystore, even if there is only one client to manage the nodes. The N nodes x N "management consoles" case requires a centralized key store, but it's not necessary to impose it on the "1 management console" case. > > > 2. A desktop key agent (eg gnome-keyring) > > > > > > This would be useful for the unprivileged libvirtd instances > > > that run in the context of the desktop login session. Users > > > already have SSH, GPG, website keys stored here, so having > > > keys for their VM disks is obviously desirable > > > > Another option here is to let the client store the secrets in > > gnome-keyring, and transfer them to libvirt only when starting > > a domain (especially when there are no persistent domains). > > That doesn't affect the design in any way, though. > > This is undesriable because it lets requires that any client which > wishes to start the guest must have access to the secrets. We really > need to be able to have separation of this, so that when we introduce > fine grained access control, you can setup separate roles for users > who can access / work with secrets, vs users who can start/define > guests. > > > > 3. A off-node key management server > > > > > > This would be useful for a large scale data center / cluster > > > cloud deployment. This is good to allow management > scalability > > > and better separation of responsiblities of adminstration. > > > > > > If no keystore is in use, then I clearly all keys must go in & > out > > > of libvirt using the XML, which is pretty much what you're doing > > > in this series. I would say though, there is no point in clearing > > > the secret from the virStorageVolDefPtr instance/XML after volume > > > creation, since the secret is going to be kept in memory forever > > > for any guest using the volume. By not clearing the secret, an > > > app could create a volume, requesting automatic key generation, > > > then just do virStorageVolDumpXML(vol, > VIR_STORAGE_VOL_XML_SECURE) > > > to extract it and pass to onto the XML for the guest that's > created > > > > That is unreliable with current implementation, because a pool refresh > > creates all information about volumes anew by reading the volume files; > > therefore, after any pool refresh libvirt "forgets" the secrets directly > > associated with a volume (not secrets associated with an use of a volume > > in a domain). If client A creates a volume, client B can refresh the > > pool before client A is able to read the automatically generated secrets. > > One of the reasons the patch is clearing the information immediately is > > to make sure a {virStorageVolCreateXML; virStorageVolGetXMLDesc) always > > fails and no client is written depending on this racy operation sequence. > > > There is another, more important, reason why the node should never return > > encryption data to anyone who can connect to it. Consider the above- > > described situation of a large-scale virtualization deployment that uses > > volume image encryption to restrict access of nodes to volume data: If > > domain migration is supported, the nodes (all of them, or at least nodes > > within some groups) must be able to connect "read-write" to other nodes. > > This is just another argument for taking clients out of the loop completely > and having libvirt daemon always talk directly with keystores. > > > With a keystore we'd likely need a handful of APIs > > > > > > - create a secret providing a passphrase > > > - list all known secret UUIDs > > > - get the passphrase assoicated with a secret > > > - delete a secret based on UUID > > > - lookup a secret UUID based on the a disk path > > > > We might not need all of these. There are three main use > > cases for storing keys outside of XML: > > > > 1) This is a "small-scale deployment", where libvirt is the > > primary key store, and anyone that is able to connect to > > libvirtd is implicitly allowed to use the secrets. In this > > case the keystore can be managed completely automatically - > > creating a volume, or perhaps using it for the first time, > > implies storing a secret, and deleting a volume implies > > deleting a secret. Secrets are identified using a volume- > > unique object (is that a path, or an UUID?), which is > > completely transparent to the client. As long as the volume > > is "known" to libvirt, the client does not even need to > > specify any <encryption> element when creating a domain. > > > > (1a, a "small-scale deployment" where there are multiple > > clients that should be protected against each other, and > > libvirt is the primary key store, does not make sense > > unless a client account system is added to libvirt. > > > 2) The secrets are primarily stored outside libvirt (to > > restrict node access to image data), and libvirt stores > > only secrets for currently defined persistent domains (to > > support domain autostart). In this case the keystore can > > be managed completely automatically - persistent domain > > definition implies storing a secret, deleting the domain > > implies deleting a secret. Secrets are identified using > > a (domain, volume) pair, and this identifier is never > > exposed to the client. > > Deleting the domain does not imply deleting a secret, since > secrets are really associated with disks, not domains. It does, in this case - if the domain is not running on the node, the secret should not be stored on the node at all. > A disk may be shared by multiple domains. If a disk is shared, there will be multiple (domain volume) key ID pairs, and deleting one instace of the secret does not delete the other. > In addition, when you delete > a domain, libvirt does not delete the disk. It is the clients > responsiblity to delete disks after the fact. In this scenario the client does the long-term key storage. libvirt does not need to - and shouldn't - store the key merely because a volume exists. > In any case items 1 & 2 are really just 2 different implementations > of the same concept. There is a keystore, and libvirt talks to > it. Whether the keystore is local, or remote from the node is a > minor impl detail. Whether libvirt can request any secret, even if does not need to know it, is not a minor detail. > Use of a keystore of some format should be our primary goal here, > since it takes the client out of the loop. When libvirt does ACLs > on clients this is even more important, because when you revoke a > clients' access to libvirt you can be sure they don't have a > record of any of the secrets, since they never had any opportunity > to see / use them during the time they were authenticated > > 3) An external key store (such as a KMIP server) is used. In this > > case the management of access rights, listing and deleting secrets, > > would be performed by interacting with the external key store > > directly. Secrets are identified by using the external key store > > identifiers, and the client and libvirtd send these identifiers to > > each other. > > As long as we allow for secrets to be passed in the XML it will always > be possible for a client to talk to a keystore, obtain the secrets and > pass them in the XML. This is really not a desirable model to aim for > by default though, because it requires clients to know about all the > different types of keystore. If a client does not know about a particular > type of keystore, then it becomes unable to manage guests on that > libvirtd. > Not to mention the issue of trust of the client & revocation of > access. > Yes, libvirt will grow the concept of a user in the future, as well as > access controls on (user, object, operation) tuples Overall, it seems this all boils down to one thing - is libvirt intended to be a simple "virtualization server" that locally performs requested operations, managed by a separate "virtualization management" client that has full knowledge about the site (nodes, storage, secrets, access rights), with clients connecting to the "virtualization management" software instead of libvirtd, or a complete "virtualization management solution" that integrates all site-wide knowedge, accessed by dumb clients using the libvirt protocol? My reading of http://www.libvirt.org/goals.html implies the former; you seem to talk about the latter model. Have I misunderstood the role of libvirt in a large-scale deployment? Thank you, Mirek

2 2

[libvirt] [PATCH] test: Generate net interface names when assigning XML.
by Cole Robinson 24 Jul '09

24 Jul '09

We need interface names to implement InterfaceStats. --- src/test.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++------ 1 files changed, 68 insertions(+), 8 deletions(-) diff --git a/src/test.c b/src/test.c index 098d235..f02b58b 100644 --- a/src/test.c +++ b/src/test.c @@ -228,6 +228,66 @@ static const unsigned long long defaultPoolAlloc = 0; static int testStoragePoolObjSetDefaults(virConnectPtr conn, virStoragePoolObjPtr pool); +static char * +testDomainGenerateIfname(virConnectPtr conn, + virDomainDefPtr domdef) { + int maxif = 1024; + int ifctr, i; + + for (ifctr = 0; ifctr < maxif; ++ifctr) { + char *ifname; + int found = 0; + + if (virAsprintf(&ifname, "testnet%d", ifctr) < 0) { + virReportOOMError(conn); + return NULL; + } + + /* Generate network interface names */ + for (i = 0 ; i < domdef->nnets ; i++) { + if (domdef->nets[i]->ifname && + STREQ (domdef->nets[i]->ifname, ifname)) { + found = 1; + break; + } + } + + if (!found) + return ifname; + } + + testError(conn, VIR_ERR_INTERNAL_ERROR, + _("Exceeded max iface limit %d"), maxif); + return NULL; +} + +static virDomainObjPtr +testDomainAssignDef(virConnectPtr conn, + virDomainObjList *domlist, + virDomainDefPtr domdef) +{ + virDomainObjPtr domobj = NULL; + int i = 0; + + for (i = 0; i < domdef->nnets; i++) { + char *ifname; + if (domdef->nets[i]->ifname) + continue; + + ifname = testDomainGenerateIfname(conn, domdef); + if (!ifname) + goto error; + + domdef->nets[i]->ifname = ifname; + } + + if (!(domobj = virDomainAssignDef(conn, domlist, domdef))) + goto error; + +error: + return domobj; +} + static int testOpenDefault(virConnectPtr conn) { int u; struct timeval tv; @@ -282,7 +342,7 @@ static int testOpenDefault(virConnectPtr conn) { defaultDomainXML, VIR_DOMAIN_XML_INACTIVE))) goto error; - if (!(domobj = virDomainAssignDef(conn, &privconn->domains, domdef))) { + if (!(domobj = testDomainAssignDef(conn, &privconn->domains, domdef))) { virDomainDefFree(domdef); goto error; } @@ -608,7 +668,7 @@ static int testOpenFromFile(virConnectPtr conn, goto error; } - if (!(dom = virDomainAssignDef(conn, &privconn->domains, def))) { + if (!(dom = testDomainAssignDef(conn, &privconn->domains, def))) { virDomainDefFree(def); goto error; } @@ -920,8 +980,8 @@ testDomainCreateXML(virConnectPtr conn, const char *xml, VIR_DOMAIN_XML_INACTIVE)) == NULL) goto cleanup; - if ((dom = virDomainAssignDef(conn, &privconn->domains, - def)) == NULL) { + if ((dom = testDomainAssignDef(conn, &privconn->domains, + def)) == NULL) { virDomainDefFree(def); goto cleanup; } @@ -1471,8 +1531,8 @@ static int testDomainRestore(virConnectPtr conn, if (!def) goto cleanup; - if ((dom = virDomainAssignDef(conn, &privconn->domains, - def)) == NULL) + if ((dom = testDomainAssignDef(conn, &privconn->domains, + def)) == NULL) goto cleanup; dom->state = VIR_DOMAIN_RUNNING; @@ -1763,8 +1823,8 @@ static virDomainPtr testDomainDefineXML(virConnectPtr conn, VIR_DOMAIN_XML_INACTIVE)) == NULL) goto cleanup; - if ((dom = virDomainAssignDef(conn, &privconn->domains, - def)) == NULL) { + if ((dom = testDomainAssignDef(conn, &privconn->domains, + def)) == NULL) { goto cleanup; } def = NULL; -- 1.6.0.6

2 2

[libvirt] [PATCH] Don't allow NULL paths for BlockStats and InterfaceStats
by Cole Robinson 24 Jul '09

24 Jul '09

Do the check in libvirt.c, to save drivers from the burden. This changes behavior slightly in the qemu driver: we no longer explictly error if passed an empty string. An error will still be thrown when the device lookup fails. --- src/libvirt.c | 4 ++-- src/qemu_driver.c | 6 ------ 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 0e6d88f..d086052 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -3578,7 +3578,7 @@ virDomainBlockStats (virDomainPtr dom, const char *path, virLibDomainError (NULL, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); return -1; } - if (!stats || size > sizeof stats2) { + if (!path || !stats || size > sizeof stats2) { virLibDomainError (dom, VIR_ERR_INVALID_ARG, __FUNCTION__); goto error; } @@ -3636,7 +3636,7 @@ virDomainInterfaceStats (virDomainPtr dom, const char *path, virLibDomainError (NULL, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); return -1; } - if (!stats || size > sizeof stats2) { + if (!path || !stats || size > sizeof stats2) { virLibDomainError (dom, VIR_ERR_INVALID_ARG, __FUNCTION__); goto error; } diff --git a/src/qemu_driver.c b/src/qemu_driver.c index c4683ae..c8f451d 100644 --- a/src/qemu_driver.c +++ b/src/qemu_driver.c @@ -5329,12 +5329,6 @@ qemudDomainInterfaceStats (virDomainPtr dom, goto cleanup; } - if (!path || path[0] == '\0') { - qemudReportError(dom->conn, dom, NULL, VIR_ERR_INVALID_ARG, - "%s", _("NULL or empty path")); - goto cleanup; - } - /* Check the path is one of the domain's network interfaces. */ for (i = 0 ; i < vm->def->nnets ; i++) { if (vm->def->nets[i]->ifname && -- 1.6.0.6

2 1