Hi, I noticed that libvirt support the following hypervisors currently:

/"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...

2012/7/4 Dennis Chen<dennis.chen(a)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.

On 07/04/2012 03:26 PM, Matthias Bolte wrote: >2012/7/4 Dennis Chen<dennis.chen(a)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?

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(a)10.30.56.60 padmin(a)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(a)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(a)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?

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/

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?

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.

> 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...