Re: Question about the Qos support status for different type interfaces

[Yalan Zhang]

Hi Michal,

Thank you for the clarification.


---
Best Regards,
Yalan Zhang
IRC: yalzhang


On Fri, Mar 26, 2021 at 8:19 PM Michal Privoznik 
wrote:

> On 3/26/21 12:31 PM, Yalan Zhang wrote:
> > Hi there,
> >
> > I have a question about the Qos support status for different type
> > interfaces.
> > Some types of interface do not support Qos, such as hostdev, user type,
> > mcast type, but the behavior are different, for hostdev, the guest can
> > not start with a meaningful error message, but for other types, vm can
> > start successfully with a warning message in the libvirtd log. I
> > doubt that if it is necessary to keep the behavior consistent for these
> > different types?
> >
> > There are 2 history bugs for them, I should have thought further and
> > asked early when testing the bugs.
> > Bug 1319044 - log
> > error when  requested on a 
> > Bug 1524230 -
> > vhostuser type interface do not support bandwidth, but no warning message
> >
> > Thank you for looking into this and very appreciate your feedback!
> >
>
> The reason is historical baggage - as usual. When QoS was fist
> introduced it supported only a very few interface types. Soon we've
> learned that users put XML snippets in for other types too. Back then we
> had no validation callbacks => we could not reject such XMLs because we
> did not do it from the beginning. So there might be some domain XMLs
> still that contain QoS for unsupported type and those would be lost if
> libvirt started rejecting such XMLs.
>
> With validation callbacks things are a bit better - the domain would not
> be lost on libvirtd upgrade; though it would still be unable to start.
> I'm not sure that's much better.
>
> Hence, we're keeping status quo. I'm open for ideas though.
>
> Michal
>
>

Re: Virtual Network API for QEMU

[Laine Stump]

On 3/27/21 8:39 AM, Radek Simko wrote:

Hi,
According to this support matrix 
https://libvirt.org/hvsupport.html#virNetworkDriver 


there is no support for any APIs other than hypervisor ones for qemu.
For example virConnectNumOfNetworks is not supported.


I'm afraid I don't understand your question. Which hypervisor are you 
using that you think virConnectNumOfNetworks isn't supported. The only 
possible meaning I can get from the above sentences is that you think 
virConnectNumOfNetworks isn't supported when qemu is the hypervisor, 
which is definitely *not* true.


As a matter of fact, essentiall *all* of the functions in the matrix are 
supported when qemu is the hypervisor, pretty much every one of them 
ever since their original introduction (e.g., the function you reference 
has been supported since libvirt 0.2.0, which was released in February 
2007).


Are you possibly misinterpreting the contents of the support matrix?

Is there any particular reason this is not supported? Has any 
development in that area been attempted in the past? Would contributions 
adding support be welcomed?


Thanks,

Radek Simko

Incremental backup utility

[Michael Ablassmeier]

hi users,

i have started a project on github that aims to create a small backup
utility, supporting the new changed block tracking features.

If anyone wants to give it a try and has some suggestions, here
is the link:

 https://github.com/abbbi/virtnbdbackup

bye,
- michael