Daniel Veillard | 3 May 14:35 2006
Picon

Re: support for hvm guests

  First sorry for being a bit late answering,

On Fri, Apr 28, 2006 at 06:07:43PM -0600, Jim Fehlig wrote:
> Type 'bridge' can be valid for hvm guests.  Perhaps it is better to not 
> expose ioemu in the XML for now as there will probably be changes in 
> this area anyway.  We know the domain is type hvm, so just add 'ioemu:' 
> where necessary when talking to xend/xenstore.  I'm currently thinking 
> about the following XML for OS element when type is hvm:
> 
> <os>
>    <type>hvm</type>
>    <kernel>/usr/lib/xen/boot/hvmloader</kernel>
>    <device_model>/usr/lib/xen/bin/qemu-dm</device_model>
>    <boot dev='c'>
>    <graphics type='vnc'>
>    <cdrom dev='/dev/hdd'>
> </os>

  Hum, I agree with Karel on the use of <boot dev='c' />, that's not really
a logical naming, can we avoid that and use more strcutured names like
'/dev/hda' .
  Also I don't understand why graphics and cdrom are not defined in the
<devices> section for example

  <devices>
    <disk type='block'>
       <source dev='hdd'/>
       <target dev='hdd'/>
       <cdrom/>
    </disk>
(Continue reading)

Jim Fehlig | 3 May 17:43 2006
Picon

Re: support for hvm guests

Daniel Veillard wrote:

>  First sorry for being a bit late answering,
>
>On Fri, Apr 28, 2006 at 06:07:43PM -0600, Jim Fehlig wrote:
>  
>
>>Type 'bridge' can be valid for hvm guests.  Perhaps it is better to not 
>>expose ioemu in the XML for now as there will probably be changes in 
>>this area anyway.  We know the domain is type hvm, so just add 'ioemu:' 
>>where necessary when talking to xend/xenstore.  I'm currently thinking 
>>about the following XML for OS element when type is hvm:
>>
>><os>
>>   <type>hvm</type>
>>   <kernel>/usr/lib/xen/boot/hvmloader</kernel>
>>   <device_model>/usr/lib/xen/bin/qemu-dm</device_model>
>>   <boot dev='c'>
>>   <graphics type='vnc'>
>>   <cdrom dev='/dev/hdd'>
>></os>
>>    
>>
>
>  Hum, I agree with Karel on the use of <boot dev='c' />, that's not really
>a logical naming, can we avoid that and use more strcutured names like
>'/dev/hda' .
>  Also I don't understand why graphics and cdrom are not defined in the
><devices> section for example
>
(Continue reading)

Daniel Veillard | 3 May 17:55 2006
Picon

Re: support for hvm guests

On Wed, May 03, 2006 at 09:43:36AM -0600, Jim Fehlig wrote:
> OK, these are great comments that I will incorporate into the patch.

  Okay thanks :-)

> Currently I can get info on hvm domains but unable to create them.  The 
> create request is sent to xend but then blocks reading from xend in 
> xend_req().  No problem creating the domain using xm.  I have looked at 
> the config coming into xend and it is identical between xm and 
> virsh/libvirt.  Need to poke around xend and see why there is no 
> response to the virsh/libvirt create request for hvm domains.

  Hum, basically to debug this kind of things I spend my time in
/var/log/xend.log especially since it prints what it received at creation
time, you can at least check the informations coming from libvirt and
from xm look alike.
  Unfortunately I won't be able to help you, first because I'm about to
take vacations for 3 weeks :-), second because I don't have one of those
new Intel CPUs, but I am sure others will give an hand if needed.

Daniel

--

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard <at> redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Jim Fehlig | 4 May 02:27 2006
Picon

Re: support for hvm guests

Daniel Veillard wrote:

>On Wed, May 03, 2006 at 09:43:36AM -0600, Jim Fehlig wrote:
>  
>
>>Currently I can get info on hvm domains but unable to create them.  The 
>>create request is sent to xend but then blocks reading from xend in 
>>xend_req().  No problem creating the domain using xm.  I have looked at 
>>the config coming into xend and it is identical between xm and 
>>virsh/libvirt.  Need to poke around xend and see why there is no 
>>response to the virsh/libvirt create request for hvm domains.
>>    
>>
>
>  Hum, basically to debug this kind of things I spend my time in
>/var/log/xend.log especially since it prints what it received at creation
>time, you can at least check the informations coming from libvirt and
>from xm look alike.
>  Unfortunately I won't be able to help you, first because I'm about to
>take vacations for 3 weeks :-), second because I don't have one of those
>new Intel CPUs, but I am sure others will give an hand if needed.
>  
>

Well, I have found the problem but not a fix :-).  When posting the 
create op to xend, the libvirt code currently waits for a response from 
xend (xend_req() is called after posting in xend_post()).  For hvm 
guests, xend does not respond and libvirt blocks indefinitely on read.  
If I skip over the call to xend_req() for the create operation, 
wait_for_devices() and subsequently unpause() are called and the hvm 
(Continue reading)

Anthony Liguori | 4 May 02:47 2006
Picon

Re: support for hvm guests

Jim Fehlig wrote:
> Daniel Veillard wrote:
>
>> On Wed, May 03, 2006 at 09:43:36AM -0600, Jim Fehlig wrote:
>>  
>>
>>> Currently I can get info on hvm domains but unable to create them.  
>>> The create request is sent to xend but then blocks reading from xend 
>>> in xend_req().  No problem creating the domain using xm.  I have 
>>> looked at the config coming into xend and it is identical between xm 
>>> and virsh/libvirt.  Need to poke around xend and see why there is no 
>>> response to the virsh/libvirt create request for hvm domains.
>>>   
>>
>>  Hum, basically to debug this kind of things I spend my time in
>> /var/log/xend.log especially since it prints what it received at 
>> creation
>> time, you can at least check the informations coming from libvirt and
>> from xm look alike.
>>  Unfortunately I won't be able to help you, first because I'm about to
>> take vacations for 3 weeks :-), second because I don't have one of those
>> new Intel CPUs, but I am sure others will give an hand if needed.
>>  
>>
>
> Well, I have found the problem but not a fix :-).  When posting the 
> create op to xend, the libvirt code currently waits for a response 
> from xend (xend_req() is called after posting in xend_post()).  For 
> hvm guests, xend does not respond and libvirt blocks indefinitely on 
> read.  If I skip over the call to xend_req() for the create operation, 
(Continue reading)

Jim Fehlig | 4 May 07:13 2006
Picon

Re: support for hvm guests

>>>> Anthony Liguori <aliguori <at> us.ibm.com> 05/03/06 6:47 PM >>>
>
>>>> Currently I can get info on hvm domains but unable to create them. 

>>>> The create request is sent to xend but then blocks reading from
xend 
>>>> in xend_req().  No problem creating the domain using xm.  I have 
>>>> looked at the config coming into xend and it is identical between
xm 
>>>> and virsh/libvirt.  Need to poke around xend and see why there is
no 
>>>> response to the virsh/libvirt create request for hvm domains.
>>>>   
>>>
>>>  Hum, basically to debug this kind of things I spend my time in
>>> /var/log/xend.log especially since it prints what it received at 
>>> creation
>>> time, you can at least check the informations coming from libvirt
and
>>> from xm look alike.
>>>  Unfortunately I won't be able to help you, first because I'm about
to
>>> take vacations for 3 weeks :-), second because I don't have one of
those
>>> new Intel CPUs, but I am sure others will give an hand if needed.
>>>  
>>>
>>
>> Well, I have found the problem but not a fix :-).  When posting the 
>> create op to xend, the libvirt code currently waits for a response 
(Continue reading)

Michel Gauthier | 4 May 18:23 2006
Picon
Picon

BUG: virDomainLookupByID fails in libvirt-0.1.0

Hi,
I tried to execute the info1 C code example on my redhat distribution with 
Xen installed.
It fails due to the virDomainLookupByID API wich returns NULL.
The problem seems to be in the internal function xenDaemonListDomains called 
after xs_get_domain_path inside the API.
For the domain 0, xs_get_domain_path returns path=/local/domain/0. Then, the 
call to xenDaemonListDomains function logs the error message:
"libvir: Xen Daemon error : could not connect to Xen Daemon"
and returns names=NULL.
A bug present in the release 0.0.6 has been fixed for the release 0.1.0. But 
this bug seems still present!

Regards. 

Jim Fehlig | 5 May 01:03 2006
Picon

Re: support for hvm guests

Anthony Liguori wrote:

> Jim Fehlig wrote:
>
>> Daniel Veillard wrote:
>>
>>> On Wed, May 03, 2006 at 09:43:36AM -0600, Jim Fehlig wrote:
>>>  
>>>
>>>> Currently I can get info on hvm domains but unable to create them.  
>>>> The create request is sent to xend but then blocks reading from 
>>>> xend in xend_req().  No problem creating the domain using xm.  I 
>>>> have looked at the config coming into xend and it is identical 
>>>> between xm and virsh/libvirt.  Need to poke around xend and see why 
>>>> there is no response to the virsh/libvirt create request for hvm 
>>>> domains.
>>>>   
>>>
>>>
>>>  Hum, basically to debug this kind of things I spend my time in
>>> /var/log/xend.log especially since it prints what it received at 
>>> creation
>>> time, you can at least check the informations coming from libvirt and
>>> from xm look alike.
>>>  Unfortunately I won't be able to help you, first because I'm about to
>>> take vacations for 3 weeks :-), second because I don't have one of 
>>> those
>>> new Intel CPUs, but I am sure others will give an hand if needed.
>>>  
>>>
(Continue reading)

Philippe Berthault | 5 May 14:52 2006
Picon
Picon

Re: BUG: virDomainLookupByID fails in libvirt-0.1.0

The problem comes from the xend configuration.

The HTTP interface of xend must be enabled to use libvirt.

Please adds the following line in your /etc/xen/xend-config.sxp file:
(xend-http-server yes)

and libvirt will be ok after restarting xend daemon.

Philippe Berthault.

Michel Gauthier a écrit :
> Hi,
> I tried to execute the info1 C code example on my redhat distribution 
> with Xen installed.
> It fails due to the virDomainLookupByID API wich returns NULL.
> The problem seems to be in the internal function xenDaemonListDomains 
> called after xs_get_domain_path inside the API.
> For the domain 0, xs_get_domain_path returns path=/local/domain/0. 
> Then, the call to xenDaemonListDomains function logs the error message:
> "libvir: Xen Daemon error : could not connect to Xen Daemon"
> and returns names=NULL.
> A bug present in the release 0.0.6 has been fixed for the release 
> 0.1.0. But this bug seems still present!
>
> Regards.
> -- 
> Libvir-list mailing list
> Libvir-list <at> redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
(Continue reading)

Karel Zak | 5 May 18:47 2006
Picon

Re: BUG: virDomainLookupByID fails in libvirt-0.1.0

On Fri, May 05, 2006 at 02:52:57PM +0200, Philippe Berthault wrote:
> The problem comes from the xend configuration.
> 
> The HTTP interface of xend must be enabled to use libvirt.
> 
> Please adds the following line in your /etc/xen/xend-config.sxp file:
> (xend-http-server yes)
> 
> and libvirt will be ok after restarting xend daemon.

 Yes. See http://libvirt.org/FAQ.html :

 3. Failure to use the API for non-root users

 Large parts of the API may only be accessible with root priviledges,
 however the read only access to the xenstore data doesnot have to be
 forbidden to user, at least for monitoring purposes. If "virsh
 dominfo" fails to run as an user, change the mode of the xenstore
 read-only socket with:

 chmod 666 /var/run/xenstored/socket_ro

 and also make sure that the Xen Daemon is running correctly with
 local HTTP server enabled, this is defined in
 /etc/xen/xend-config.sxp which need the following line to be enabled:

 (xend-http-server yes)

 If needed restart the xend daemon after making the change with the
 following command run as root:
(Continue reading)


Gmane