Re: [libvirt-users] Libvirt API for getting disk capacity from VM XML

2019-06-14 Thread Martin Kletzander

On Thu, Jun 13, 2019 at 03:17:16PM +0530, Varsha Verma wrote:

Hello everyone,
I am doing an outreachy internship at Openstack Ironic. In the sushy-tools
project, we are using libvirt VMs to simulate bare metal machines for
testing purposes.

In the XML description of a domain, there are a bunch of disk elements
giving information about the various storage devices attached to the
domain. Is there some way to get the size/capacity of those disks using the
libvirt API?



Yes, there is, virStorageVolGetXMLDesc:

 https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolGetXMLDesc

Look for 

The tricky part might be to get the storage volume object.  I'm not sure how
sushy-tools are using libvirt and what the deployment looks like, so here are
few tips and feel free to ask for more info.

If it is a path on the local filesystem, you might just use
`virStorageVolLookupByKey` and be done with it:

 https://libvirt.org/html/libvirt-libvirt-storage.html#virStorageVolLookupByKey

If it is not, you might need to look it up based on the pool it is in.

If you have the pool already, then it is a matter of `virStorageVolLookupBy*`
for example.  If you don't have that you might look for the pool with
`virStoragePoolLookupBy*`, for example `virStoragePoolLookupByName`:

 
https://libvirt.org/html/libvirt-libvirt-storage.html#virStoragePoolLookupByName

And one more general libvirt advice (although maybe not really a good one,
definitely not a silver bullet):

You can always have a look at how `virsh` does things.  It might be a bit
confusing at times, but if you have a command name (in our case we'd use the
`vol-dumpxml` command), you can CamelCase it ("VolDumpXML"), prepend "cmd" (as
in "command") and the resulting name (`cmdVolDumpXML`) is the name of the
function that virsh runs for that command.  You can see it in
tools/virsh-volume.c:

 https://github.com/libvirt/libvirt/blob/master/tools/virsh-volume.c#L1211

The main part of how it looks up a volume is `virshCommandOptVol` which is just
a syntax sugar for `virshCommandOptVolBy` in the same file:

 https://github.com/libvirt/libvirt/blob/master/tools/virsh-volume.c#L68

Which is trying to do the lookup by all various possible things.  Same thing can
be found for `pool-*` commands.

HTH, have a nice day,
Martin


--

*Regards,*

*Varsha Verma*

*Fourth Year Undergraduate*

*Department of Electrical Engineering*

*IIT-BHU, Varanasi*



___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users




signature.asc
Description: PGP signature
___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] blockcommit of domain not successfull

2019-06-14 Thread Lentes, Bernd



- On Jun 14, 2019, at 9:14 AM, Peter Krempa pkre...@redhat.com wrote:

> On Thu, Jun 13, 2019 at 16:01:18 +0200, Lentes, Bernd wrote:
>> 
>> - On Jun 13, 2019, at 1:08 PM, Bernd Lentes
>> bernd.len...@helmholtz-muenchen.de wrote:
>> 
>> I found further information in /var/log/messages for both occurrences:
>> 
>> 2019-06-01T03:05:31.620725+02:00 ha-idg-2 systemd-coredump[14253]: Core 
>> Dumping
>> has been disabled for process 30590 (qemu-system-x86).
>> 2019-06-01T03:05:31.712673+02:00 ha-idg-2 systemd-coredump[14253]: Process 
>> 30590
>> (qemu-system-x86) of user 488 dumped core.
>> 2019-06-01T03:05:32.173272+02:00 ha-idg-2 kernel: [294682.387828] br0: port
>> 4(vnet2) entered disabled state
>> 2019-06-01T03:05:32.177111+02:00 ha-idg-2 kernel: [294682.388384] device 
>> vnet2
>> left promiscuous mode
>> 2019-06-01T03:05:32.177122+02:00 ha-idg-2 kernel: [294682.388391] br0: port
>> 4(vnet2) entered disabled state
>> 2019-06-01T03:05:32.208916+02:00 ha-idg-2 wickedd[2954]: error retrieving tap
>> attribute from sysfs
>> 2019-06-01T03:05:41.395685+02:00 ha-idg-2 systemd-machined[2824]: Machine
>> qemu-31-severin terminated.
>> 
>> 
>> 2019-06-08T05:59:17.502899+02:00 ha-idg-1 systemd-coredump[31089]: Core 
>> Dumping
>> has been disabled for process 19489 (qemu-system-x86).
>> 2019-06-08T05:59:17.523050+02:00 ha-idg-1 systemd-coredump[31089]: Process 
>> 19489
>> (qemu-system-x86) of user 489 dumped core.
>> 2019-06-08T05:59:17.650334+02:00 ha-idg-1 kernel: [999258.577132] br0: port
>> 9(vnet7) entered disabled state
>> 2019-06-08T05:59:17.650354+02:00 ha-idg-1 kernel: [999258.578103] device 
>> vnet7
>> left promiscuous mode
>> 2019-06-08T05:59:17.650355+02:00 ha-idg-1 kernel: [999258.578108] br0: port
>> 9(vnet7) entered disabled state
>> 2019-06-08T05:59:25.983702+02:00 ha-idg-1 systemd-machined[1383]: Machine
>> qemu-205-severin terminated.
>> 
>> Core Dumping is disabled, but nevertheless a core dump has been created ?
>> Where could i find it ?
>> Would it be useful to provide it ?
> 
> So this really hints to qemu crashing. It certainly will be beneficial
> to collect the backtrace, but you really should report this (including
> the error message from the vm log file) to the qemu team.
> 
> They might have even fixed it by now, so a plain update might help.

Hi Peter,

thanks for your help. I'll continue on the Qemu ML:
https://lists.nongnu.org/archive/html/qemu-discuss/2019-06/msg00014.html


Bernd
 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Prof. Dr. Veronika von Messling
Geschaeftsfuehrung: Prof. Dr. med. Dr. h.c. Matthias Tschoep, Heinrich Bassler, 
Kerstin Guenther
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users


[libvirt-users] Libvirt API for getting disk capacity from VM XML

2019-06-14 Thread Varsha Verma
Hello everyone,
I am doing an outreachy internship at Openstack Ironic. In the sushy-tools
project, we are using libvirt VMs to simulate bare metal machines for
testing purposes.

In the XML description of a domain, there are a bunch of disk elements
giving information about the various storage devices attached to the
domain. Is there some way to get the size/capacity of those disks using the
libvirt API?

-- 

*Regards,*

*Varsha Verma*

*Fourth Year Undergraduate*

*Department of Electrical Engineering*

*IIT-BHU, Varanasi*
___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] blockcommit of domain not successfull

2019-06-14 Thread Peter Krempa
On Thu, Jun 13, 2019 at 16:01:18 +0200, Lentes, Bernd wrote:
> 
> - On Jun 13, 2019, at 1:08 PM, Bernd Lentes 
> bernd.len...@helmholtz-muenchen.de wrote:
> 
> I found further information in /var/log/messages for both occurrences:
> 
> 2019-06-01T03:05:31.620725+02:00 ha-idg-2 systemd-coredump[14253]: Core 
> Dumping has been disabled for process 30590 (qemu-system-x86).
> 2019-06-01T03:05:31.712673+02:00 ha-idg-2 systemd-coredump[14253]: Process 
> 30590 (qemu-system-x86) of user 488 dumped core.
> 2019-06-01T03:05:32.173272+02:00 ha-idg-2 kernel: [294682.387828] br0: port 
> 4(vnet2) entered disabled state
> 2019-06-01T03:05:32.177111+02:00 ha-idg-2 kernel: [294682.388384] device 
> vnet2 left promiscuous mode
> 2019-06-01T03:05:32.177122+02:00 ha-idg-2 kernel: [294682.388391] br0: port 
> 4(vnet2) entered disabled state
> 2019-06-01T03:05:32.208916+02:00 ha-idg-2 wickedd[2954]: error retrieving tap 
> attribute from sysfs
> 2019-06-01T03:05:41.395685+02:00 ha-idg-2 systemd-machined[2824]: Machine 
> qemu-31-severin terminated.
> 
> 
> 2019-06-08T05:59:17.502899+02:00 ha-idg-1 systemd-coredump[31089]: Core 
> Dumping has been disabled for process 19489 (qemu-system-x86).
> 2019-06-08T05:59:17.523050+02:00 ha-idg-1 systemd-coredump[31089]: Process 
> 19489 (qemu-system-x86) of user 489 dumped core.
> 2019-06-08T05:59:17.650334+02:00 ha-idg-1 kernel: [999258.577132] br0: port 
> 9(vnet7) entered disabled state
> 2019-06-08T05:59:17.650354+02:00 ha-idg-1 kernel: [999258.578103] device 
> vnet7 left promiscuous mode
> 2019-06-08T05:59:17.650355+02:00 ha-idg-1 kernel: [999258.578108] br0: port 
> 9(vnet7) entered disabled state
> 2019-06-08T05:59:25.983702+02:00 ha-idg-1 systemd-machined[1383]: Machine 
> qemu-205-severin terminated.
> 
> Core Dumping is disabled, but nevertheless a core dump has been created ?
> Where could i find it ?
> Would it be useful to provide it ?

So this really hints to qemu crashing. It certainly will be beneficial
to collect the backtrace, but you really should report this (including
the error message from the vm log file) to the qemu team.

They might have even fixed it by now, so a plain update might help.


signature.asc
Description: PGP signature
___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users