On 07/04/2012 03:26 PM, Matthias Bolte wrote:

2012/7/4 Dennis Chen<dennis.chen@tnsoft.com.cn>:

...

Hi,

I noticed that libvirt support the following hypervisors currently:

The KVM/QEMU Linux hypervisor The Xen hypervisor on Linux and Solaris hosts. The LXC Linux container system The OpenVZ Linux container system The User Mode Linux paravirtualized kernel The VirtualBox hypervisor The VMware ESX and GSX hypervisors The VMware Workstation and Player hypervisors The Microsoft Hyper-V hypervisor

"the goal of libvirt: to provide a common and stable layer sufficient to securely manage domains on a node, possibly remote."

My question is, does redhat's libvirt team have the plan to support IBM PowerVM hypervisor? If the answer is NO, what's the reason to make the support for IBM PowerVM hypervisor doesn't make sense... Well, libvirt aleady has support for the 'IBM Power Hypervisor' for a while now, called 'phyp' internally in the codebase, see

http://libvirt.org/git/?p=libvirt.git;a=tree;f=src/phyp

It's just lacking documentation and for some unknown reason is not mentioned on the homepage. We should fix this.

Adding Eduardo who is the author of the phyp driver... Eduardo, is the libvirtd daemon necessary for libvirt-based to manage the PowerVM node? I guess so, if it's the case, then what's the environment in the PowerVM-based node to run the libvirtd daemon, is it vios? BRs, Dennis

On 07/04/2012 08:56 PM, Eduardo Otubo wrote:

On Wed, Jul 04, 2012 at 05:42:08PM +0800, Dennis Chen wrote:

...

Adding Eduardo who is the author of the phyp driver...

Eduardo, is the libvirtd daemon necessary for libvirt-based to manage the PowerVM node? I guess so, if it's the case, then what's the environment in the PowerVM-based node to run the libvirtd daemon, is it vios? Dennis,

libvirtd isn't necessary to manage LPARs. You just need to run virsh in your own computer in order to connect to an HMC/VIOS or IVM environment.

Any questions please feel free to ask.

Regards,

Eduardo, Thanks for the help! I encounter an issue when trying to connect the remote VIOS/IVM server: 1. The used virsh is built from 0.9.12 source code with ./configure --prefix=/usr --with-phyp; make; make install; 2. When I try to connect the VIOS server with ssh, it succeeds with output looks like: root@dennis-:/home/libvirt-0.9.12# ssh padmin@10.30.56.60 padmin@172.30.56.60's password: Last unsuccessful login: Wed Jul 4 21:22:22 CDT 2012 on ssh from 10.16.10.94 Last login: Wed Jul 4 21:23:14 CDT 2012 on /dev/pts/1 from 10.16.10.94 [vios:/home/padmin] 3. My virsh runs in the local ubuntu 12.04 system, and I've executed the following command: sudo usermod -G libvirtd -a padmin 4. When I try connect the VIOS server with virsh, issue occurs: root@dennis-:/home/libvirt-0.9.12# virsh -c phyp://padmin@10.30.56.60 Enter padmin's password for 10.30.56.60: error: An error occurred, but the cause is unknown error: failed to connect to the hypervisor root@dennis-:/home/libvirt-0.9.12# virsh -c phyp+ssh://padmin@10.30.56.60 padmin@10.30.56.60's password: error: End of file while reading data: bash: sh: command not found: Input/output error error: failed to connect to the hypervisor some times the last command also shows error message like: root@dennis-:/home/libvirt-0.9.12# virsh -c phyp+ssh://padmin@10.30.56.60 padmin@10.30.56.60's password: error: Cannot recv data: bash: sh: command not found: Connection reset by peer error: failed to connect to the hypervisor Is there any tips about this? BRs, Dennis

On 07/10/2012 10:23 PM, Eduardo Otubo wrote:

On Thu, Jul 05, 2012 at 10:50:11AM +0800, Dennis Chen wrote:

...

Eduardo,

Thanks for the help! I encounter an issue when trying to connect the remote VIOS/IVM server:

1. The used virsh is built from 0.9.12 source code with ./configure --prefix=/usr --with-phyp; make; make install;

2. When I try to connect the VIOS server with ssh, it succeeds with output looks like: root@dennis-:/home/libvirt-0.9.12# ssh padmin@10.30.56.60 padmin@172.30.56.60's password: Last unsuccessful login: Wed Jul 4 21:22:22 CDT 2012 on ssh from 10.16.10.94 Last login: Wed Jul 4 21:23:14 CDT 2012 on /dev/pts/1 from 10.16.10.94 [vios:/home/padmin]

3. My virsh runs in the local ubuntu 12.04 system, and I've executed the following command: sudo usermod -G libvirtd -a padmin

4. When I try connect the VIOS server with virsh, issue occurs:

root@dennis-:/home/libvirt-0.9.12# virsh -c phyp://padmin@10.30.56.60 Enter padmin's password for 10.30.56.60: error: An error occurred, but the cause is unknown error: failed to connect to the hypervisor

root@dennis-:/home/libvirt-0.9.12# virsh -c phyp+ssh://padmin@10.30.56.60 padmin@10.30.56.60's password: error: End of file while reading data: bash: sh: command not found: Input/output error error: failed to connect to the hypervisor

some times the last command also shows error message like: root@dennis-:/home/libvirt-0.9.12# virsh -c phyp+ssh://padmin@10.30.56.60 padmin@10.30.56.60's password: error: Cannot recv data: bash: sh: command not found: Connection reset by peer error: failed to connect to the hypervisor

Is there any tips about this? Sorry for the late reply.

You must connect to the HMC instead of the VIOS - VIOS commands will be transparently passed along the HMC tunnel. You also must specify the managed system name in the command line:

$ virsh -c phyp://user@[hmc|ivm]/managed_system

I'll try to post a patch this week to update the documentation. Any issues please feel free to ping me in the IRC as well.

phyp driver is important for our project, so I am trying to debug it these days, yes, the uri should be: phyp://user@hmc_server/managed_system. And I made some progress, hopefully I can resolve the connection issue finally. Now the phyp driver can connect to the remote HMC server successfully, but seems the phyp uri conflicts with the libvirt remote driver, so after connection, the "virsh # list" command followed will result in "segment fault" error, I found that the reason is "remoteGenericOpen" called in the do_open will clear the virConnectPtr conn->networkPrivatedata, maybe we need a patch to fix that. BRs, Dennis

On 07/05/2012 03:40 AM, Dennis Chen wrote:

Hi libvirt team,

I found there are very few documents to mention how to launch a libvirtd daemon when built from the source code.

That's because the daemon is usually launched by installing a package via your distro package manager, rather than manually.

A moment ago, I un-install all the kvm related stuff (kvm module, libvirt, virt-manager, virsh, qemu-kvm...) from my ubuntu system.

That means you uninstalled the service setups.

Then I built the libvirt from the source tar package:

1. #./autogen.sh --system --with-phyp --enable-debug=yes CFLAGS=-g

This works for building a libvirtd that can be run in place of an installed one, but...

2. #make 3. #make install

...does NOT install services. That is, developers use ./autogen.sh to reuse their existing service setup from the distro installation alongside their in-tree libvirtd to test out new libvirtd features. Side note: './autogen.sh --system' is currently hard-coded to Fedora distro layout; if Ubuntu has picked a different installation layout, then it might not work. Patches to ./autogen.sh are welcome (I don't use Ubuntu often enough myself to know if this is an actual or just a theoretical issue).

Everything is OK :), but wait a minute --

According to the instruction in libvirt.org, the option flag "--system" in above step 1 will make the environment is the same as the pre-built package installation, eg, apt-get install ... because I found that the "libvirtd" daemon is not active with "ps aux | grep libvirtd", so I try to start it manually:

Method 1: root@dennis-:/home/dennis/workspace/AIX# service libvirtd start libvirtd: unrecognized service

That's because your distro packaging takes additional steps beyond 'make install' in order to actually activate the service. I don't know what those steps are for Ubuntu, but I do know that in libvirt.spec.in, you can find those additional steps for a Fedora system (and it differs for Fedora 15 vs. Fedora 16 to match Fedora's change from initd to systemd as the service manager - which explains why 'make install' does not worry about distro-specific details like how to install a service).

Method 2: root@dennis-:/home/dennis/workspace/AIX# /etc/init.d/libvirtd start bash: /etc/init.d/libvirtd: No such file or directory

Again, that sounds like a distro-specific file included in part of the packaging beyond what 'make install' provides.

Method 3: root@dennis-:/home/dennis/workspace/AIX# /usr/sbin/libvirtd start

'libvirtd' does not take a 'start' argument; but you are correct that you can manually run libvirtd with correct permissions instead of having a service run it, for testing out functionality.

2012-07-05 09:20:42.225+0000: 32749: info : libvirt version: 0.9.12 2012-07-05 09:20:42.225+0000: 32749: error : virDomainDefParseXML:8303 : unknown OS type hvm

That error message could perhaps be improved to list _which_ domain cannot be parsed. I know at one point we cleaned up our code to start warning about unknown OS type instead of silently ignoring it; it may be that you have effectively upgraded from an older version of libvirt that ignored bad XML and your self-built libvirtd is warning. Is libvirtd still running at this point, though?

I don't know if the method 3 is success or not, but I have no time to verify it now, because I have to leave the office now for the later traffic jam... Why "unknow OS type hvm"?

If my experiment is useful, then please document it in the libvirt.org page...

Patches welcome. The libvirt.org page is generated from libvirt.git/docs/ -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

Hi, I plan to use virCgroupSetCpuCfsPeriod() and virCgroupSetCpuCfsQuota() to control cpu bandwidth with help of cgroup, so I need to instantiate the cgroup parameter first for the calling of virCgroupSetCpuCfsPeriod, below is my code piece: 1 virConnectPtr conn; 2 struct qemud_driver *driver; 3 conn = virConnectOpen("qemu:///system"); 4 driver = conn->privateData; 5 virCgroupSetCpuCfsPeriod(driver->cgroup, cfs_period); then I get an compiling error in line 4: error: dereferencing pointer to incomplete type I know the reason is the actual definition of virConnectPtr is in datatyps.h, but it's not reasonable or ugly to include this file in my project. So my question is, is there any API that I can get the driver instance from virConnectPtr conn in the libvirt? Thanks, Dennis

On 11/21/2012 05:34 PM, Daniel P. Berrange wrote:

On Wed, Nov 21, 2012 at 05:24:18PM +0800, Dennis Chen wrote:

...

Hi,

I plan to use virCgroupSetCpuCfsPeriod() and virCgroupSetCpuCfsQuota() to control cpu bandwidth with help of cgroup, so I need to instantiate the cgroup parameter first for the calling of virCgroupSetCpuCfsPeriod, below is my code piece:

1 virConnectPtr conn; 2 struct qemud_driver *driver;

3 conn = virConnectOpen("qemu:///system"); 4 driver = conn->privateData; 5 virCgroupSetCpuCfsPeriod(driver->cgroup, cfs_period);

then I get an compiling error in line 4: error: dereferencing pointer to incomplete type

I know the reason is the actual definition of virConnectPtr is in datatyps.h, but it's not reasonable or ugly to include this file in my project. datatypes.h is an internal *private* header file which applications cannot use.

...

So my question is, is there any API that I can get the driver instance from virConnectPtr conn in the libvirt? No, this is internal code. Your connection to libvirtd goes over an RPC protocol, so there is no way for you to directly access this. You must only use the public APis in libvirt.h or virterror.h

Daniel

Yeah, I know. So the email is try to get to know how to use cgroup to configure the cpu bandwidth of a specific VM, I am writing a separate project to control the cfs bandwidth of a VM specified, not taking use of the virsh shell. Any tips? Thanks, Dennis

On 11/21/2012 10:00 PM, Eric Blake wrote:

On 11/21/2012 02:42 AM, Dennis Chen wrote:

[I will note that today's email chain should have been as a new thread, rather than in-reply to a thread from July - changing subject lines and deleting all previous content still doesn't stop your mailer from using In-Reply-To headers]

...

Yeah, I know. So the email is try to get to know how to use cgroup to configure the cpu bandwidth of a specific VM, I am writing a separate project to control the cfs bandwidth of a VM specified, not taking use of the virsh shell. You do this by modifying the domain XML:

http://libvirt.org/formatdomain.html#elementsCPUTuning

documents the<cputune> element, which includes the shares, period, and quota tunables that map into the cpu bandwidth cgroup tunables. So, rather than directly modifying cgroup, you should instead be modifying this portion of the XML.

Furthermore, if your domain is already running, then you can hotplug the tuning via the virDomainGetSchedulerParametersFlags() and virDomainSetSchedulerParametersFlags() API, with parameter names such as VIR_DOMAIN_SCEDULER_VCPU_PERIOD which maps back to the<period> sub-element of the<cputune> domain XML. These APIs are already exposed via the 'virsh schedinfo' command.

Hi Eric, Those APIs are really the one I needed, thanks very much for the help. After a rough test, it works! though, I can't find the VIR_DOMAIN_SCEDULER_VCPU_PERIOD macro in the libvirt source code... BRs, Dennis