Xen devel - Jun 2010 - [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Well, I did send an e-mail to the list using git but it''s not here so 
I''m forwarding the e-mail to the list for sure:]

Hi,
this is the patch for qemu-xen-3.4-testing to fix the read-only
image file handling since the image file was always treated as
read-write which means that all the HVM guests were able to
write to all the disk images available in domain configuration
file no matter what the mode of the image was defined. This
patch fixes this functionality to honor the O_RDONLY in the
BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI
interfaces that uses it.

It''s been tested on RHEL-5 with xen-3.4-testing version of
upstream xen with xen-3.4-testing qemu implementation.

For SCSI devices the DATA PROTECT request sense has been added
as found at: http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command

Michal

Signed-off-by: Michal Novotny <minovotn@redhat.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Oh, just one more thing that should be mentioned:

When you want to mount an image that is set as read-only in the domain 
configuration file but you omit to set mode to read-only it results into 
I/O errors when processing the requests. Remounting as read-only or 
unmounting and remounting using the `mount /dev/* /path/to/mount -o ro` 
shall do the mounting the correct way, i.e. with no I/O errors, so make 
sure you mount those disks as read-only otherwise you can be getting 
errors like:

end_request: I/O error, dev hdb, sector 52

Buffer I/O error on device hdb1, logical block 1

lost page write due to I/O error on hdb1


and for IDE devices you''ll be getting several additional DeviceFault 
errors since mounting the device read-write (default setting) writes 
some data onto a disk at the mount-time.

Michal

On 06/03/2010 04:04 PM, Michal Novotny wrote:
> [Well, I did send an e-mail to the list using git but it''s not
here so
> I''m forwarding the e-mail to the list for sure:]
>
> Hi,
> this is the patch for qemu-xen-3.4-testing to fix the read-only
> image file handling since the image file was always treated as
> read-write which means that all the HVM guests were able to
> write to all the disk images available in domain configuration
> file no matter what the mode of the image was defined. This
> patch fixes this functionality to honor the O_RDONLY in the
> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI
> interfaces that uses it.
>
> It''s been tested on RHEL-5 with xen-3.4-testing version of
> upstream xen with xen-3.4-testing qemu implementation.
>
> For SCSI devices the DATA PROTECT request sense has been added
> as found at: http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>
> file no matter what the mode of the image was defined. This
> patch fixes this functionality to honor the O_RDONLY in the
> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI
> interfaces that uses it.
>
> It''s been tested on RHEL-5 with xen-3.4-testing version of
> Michal
>
> Signed-off-by: Michal Novotny <minovotn@redhat.com>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Oh, one more thing I''ve discovered now. Since the codebase for 
qemu-xen-unstable is looking the same like for qemu-xen-3.4-testing and 
the patch is applicable without any modifications it could be working 
for xen-4.1 unstable as well, unfortunately I was not able to boot PVOPS 
kernel since it always ends up in kernel panic, maybe the missing 
drivers or something like that. Could anybody please test my patch with 
qemu-xen-unstable to see if it''s working?

Thanks a lot!

Michal

On 06/03/2010 04:12 PM, Michal Novotny wrote:
> Oh, just one more thing that should be mentioned:
>
> When you want to mount an image that is set as read-only in the domain 
> configuration file but you omit to set mode to read-only it results 
> into I/O errors when processing the requests. Remounting as read-only 
> or unmounting and remounting using the `mount /dev/* /path/to/mount -o 
> ro` shall do the mounting the correct way, i.e. with no I/O errors, so 
> make sure you mount those disks as read-only otherwise you can be 
> getting errors like:
>
> end_request: I/O error, dev hdb, sector 52
>
> Buffer I/O error on device hdb1, logical block 1
>
> lost page write due to I/O error on hdb1
>
>
> and for IDE devices you''ll be getting several additional
DeviceFault
> errors since mounting the device read-write (default setting) writes 
> some data onto a disk at the mount-time.
>
> Michal
>
> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>> [Well, I did send an e-mail to the list using git but it''s not
here
>> so I''m forwarding the e-mail to the list for sure:]
>>
>> Hi,
>> this is the patch for qemu-xen-3.4-testing to fix the read-only
>> image file handling since the image file was always treated as
>> read-write which means that all the HVM guests were able to
>> write to all the disk images available in domain configuration
>> file no matter what the mode of the image was defined. This
>> patch fixes this functionality to honor the O_RDONLY in the
>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI
>> interfaces that uses it.
>>
>> It''s been tested on RHEL-5 with xen-3.4-testing version of
>> upstream xen with xen-3.4-testing qemu implementation.
>>
>> For SCSI devices the DATA PROTECT request sense has been added
>> as found at: http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>
>> file no matter what the mode of the image was defined. This
>> patch fixes this functionality to honor the O_RDONLY in the
>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI
>> interfaces that uses it.
>>
>> It''s been tested on RHEL-5 with xen-3.4-testing version of
>> Michal
>>
>> Signed-off-by: Michal Novotny <minovotn@redhat.com>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal Novotny
wrote:
> Oh, one more thing I''ve discovered now. Since the codebase for  
> qemu-xen-unstable is looking the same like for qemu-xen-3.4-testing and  
> the patch is applicable without any modifications it could be working  
> for xen-4.1 unstable as well, unfortunately I was not able to boot PVOPS  
> kernel since it always ends up in kernel panic, maybe the missing  
> drivers or something like that.
>
What kernel version? Did you use xen/stable-2.6.32.x branch from xen.git? 

See my example .config files from:
http://wiki.xensource.com/xenwiki/XenParavirtOps in the
"troubleshooting" section.

Works on F12/F13 dom0''s. 

For el5 dom0 you might need these:
http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher

aka
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y

Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y in the .config
because of the recently added pv-on-hvm drivers (you''ll get build
failure without that option),
so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or XEN_NETDEV_FRONTEND or
XEN_FBDEV_FRONTEND needs to be =y.

-- Pasi

> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>> Oh, just one more thing that should be mentioned:
>>
>> When you want to mount an image that is set as read-only in the domain
>> configuration file but you omit to set mode to read-only it results  
>> into I/O errors when processing the requests. Remounting as read-only  
>> or unmounting and remounting using the `mount /dev/* /path/to/mount -o
>> ro` shall do the mounting the correct way, i.e. with no I/O errors, so
>> make sure you mount those disks as read-only otherwise you can be  
>> getting errors like:
>>
>> end_request: I/O error, dev hdb, sector 52
>>
>> Buffer I/O error on device hdb1, logical block 1
>>
>> lost page write due to I/O error on hdb1
>>
>>
>> and for IDE devices you''ll be getting several additional
DeviceFault
>> errors since mounting the device read-write (default setting) writes  
>> some data onto a disk at the mount-time.
>>
>> Michal
>>
>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>> [Well, I did send an e-mail to the list using git but it''s
not here
>>> so I''m forwarding the e-mail to the list for sure:]
>>>
>>> Hi,
>>> this is the patch for qemu-xen-3.4-testing to fix the read-only
>>> image file handling since the image file was always treated as
>>> read-write which means that all the HVM guests were able to
>>> write to all the disk images available in domain configuration
>>> file no matter what the mode of the image was defined. This
>>> patch fixes this functionality to honor the O_RDONLY in the
>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI
>>> interfaces that uses it.
>>>
>>> It''s been tested on RHEL-5 with xen-3.4-testing version of
>>> upstream xen with xen-3.4-testing qemu implementation.
>>>
>>> For SCSI devices the DATA PROTECT request sense has been added
>>> as found at:
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>
>>> file no matter what the mode of the image was defined. This
>>> patch fixes this functionality to honor the O_RDONLY in the
>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI
>>> interfaces that uses it.
>>>
>>> It''s been tested on RHEL-5 with xen-3.4-testing version of
>>> Michal
>>>
>>> Signed-off-by: Michal Novotny <minovotn@redhat.com>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>
>>
>
>
> -- 
> Michal Novotny<minovotn@redhat.com>, RHCE
> Virtualization Team (xen userspace), Red Hat
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal Novotny wrote:
>    
>> Oh, one more thing I''ve discovered now. Since the codebase for
>> qemu-xen-unstable is looking the same like for qemu-xen-3.4-testing and
>> the patch is applicable without any modifications it could be working
>> for xen-4.1 unstable as well, unfortunately I was not able to boot
PVOPS
>> kernel since it always ends up in kernel panic, maybe the missing
>> drivers or something like that.
>>
>>      
> What kernel version? Did you use xen/stable-2.6.32.x branch from xen.git?
>    
It''s the one that''s being automatically downloaded from git as
linux-2.6-pvops.git. The URL is 
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git with the 
"fetch" being set to "+refs/heads/*:refs/remotes/xen/*".
This is the
.git/config automatically created by `make world` in xen-unstable tree:

[core]
         repositoryformatversion = 0
         filemode = true
         bare = false
         logallrefupdates = true
[remote "xen"]
         url = git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
         fetch = +refs/heads/*:refs/remotes/xen/*
[branch "xen/stable-2.6.31.x"]
         remote = xen
         merge = refs/heads/xen/stable-2.6.31.x

By default it''s using uhci-hcd/ehci-hcd and ohci-hcd as builtins but I 
needed to change it to be modules since otherwise it''s being stuck.
I''m
trying this on RHEL-5 dom0 (I''m having second partition RHEL-5 with 
upstream xen).
> See my example .config files from:
> http://wiki.xensource.com/xenwiki/XenParavirtOps in the
"troubleshooting" section.
>    
I''ll have a look, thanks for the link.
> Works on F12/F13 dom0''s.
>
> For el5 dom0 you might need these:
> http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>    
Oh, ok, this may be very useful since I''m trying this on RHEL-5.
Thanks!
> aka
> CONFIG_SYSFS_DEPRECATED=y
> CONFIG_SYSFS_DEPRECATED_V2=y
>
> Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y in the .config
> because of the recently added pv-on-hvm drivers (you''ll get build
failure without that option),
> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or XEN_NETDEV_FRONTEND
or XEN_FBDEV_FRONTEND needs to be =y.
>
>    
Great! Thanks for your help Pasi! If anything I''ll let you know.

Michal
> -- Pasi
>
>
>    
>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>      
>>> Oh, just one more thing that should be mentioned:
>>>
>>> When you want to mount an image that is set as read-only in the
domain
>>> configuration file but you omit to set mode to read-only it results
>>> into I/O errors when processing the requests. Remounting as
read-only
>>> or unmounting and remounting using the `mount /dev/* /path/to/mount
-o
>>> ro` shall do the mounting the correct way, i.e. with no I/O errors,
so
>>> make sure you mount those disks as read-only otherwise you can be
>>> getting errors like:
>>>
>>> end_request: I/O error, dev hdb, sector 52
>>>
>>> Buffer I/O error on device hdb1, logical block 1
>>>
>>> lost page write due to I/O error on hdb1
>>>
>>>
>>> and for IDE devices you''ll be getting several additional
DeviceFault
>>> errors since mounting the device read-write (default setting)
writes
>>> some data onto a disk at the mount-time.
>>>
>>> Michal
>>>
>>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>>        
>>>> [Well, I did send an e-mail to the list using git but
it''s not here
>>>> so I''m forwarding the e-mail to the list for sure:]
>>>>
>>>> Hi,
>>>> this is the patch for qemu-xen-3.4-testing to fix the read-only
>>>> image file handling since the image file was always treated as
>>>> read-write which means that all the HVM guests were able to
>>>> write to all the disk images available in domain configuration
>>>> file no matter what the mode of the image was defined. This
>>>> patch fixes this functionality to honor the O_RDONLY in the
>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI
>>>> interfaces that uses it.
>>>>
>>>> It''s been tested on RHEL-5 with xen-3.4-testing
version of
>>>> upstream xen with xen-3.4-testing qemu implementation.
>>>>
>>>> For SCSI devices the DATA PROTECT request sense has been added
>>>> as found at:
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>
>>>> file no matter what the mode of the image was defined. This
>>>> patch fixes this functionality to honor the O_RDONLY in the
>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI
>>>> interfaces that uses it.
>>>>
>>>> It''s been tested on RHEL-5 with xen-3.4-testing
version of
>>>> Michal
>>>>
>>>> Signed-off-by: Michal Novotny<minovotn@redhat.com>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>>          
>>>
>>>        
>>
>> -- 
>> Michal Novotny<minovotn@redhat.com>, RHCE
>> Virtualization Team (xen userspace), Red Hat
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>      

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Well, now the kernel is booting but when I''m trying to recompile tools 
and stubdom images it''s not OK returning those errors:

...
qemu successfuly configured for Xen qemu-dm build
make -C ioemu-dir install
=== PCI passthrough capability has been enabled ==make[3]: Entering directory 
`/home2/shared/xen-unstable.hg/tools/ioemu-remote''
=== PCI passthrough capability has been enabled ===== PCI passthrough capability
has been enabled ==make[4]: Entering directory
`/home2/shared/xen-unstable.hg/tools/ioemu-remote/i386-dm''
CC i386-dm/vl.o
/home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c: In function ‘main’:
/home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c:5729: warning: 
implicit declaration of function ‘dma_helper_init’
/home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c:5731: error: too few 
arguments to function ‘xc_interface_open’
make[4]: *** [vl.o] Error 1
make[4]: Leaving directory 
`/home2/shared/xen-unstable.hg/tools/ioemu-remote/i386-dm''
make[3]: *** [subdir-i386-dm] Error 2
make[3]: Leaving directory 
`/home2/shared/xen-unstable.hg/tools/ioemu-remote''
make[2]: *** [subdir-install-ioemu-dir] Error 2
make[2]: Leaving directory `/home2/shared/xen-unstable.hg/tools''
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home2/shared/xen-unstable.hg/tools''
make: *** [install-tools] Error 2
#

The command I used for compilation is `make install-xen && make 
install-tools && make install-stubdom && make install-docs` on
the
latest updated xen-unstable staging mercurial tree so I need to 
investigate this further. Nevertheless, the dom0 2.6.31.13 is booting on 
RHEL-5 which is good. That links you gave me Pasi helped, thanks! Now I 
need to resolve those tools issues.

Michal

On 06/04/2010 12:57 PM, Michal Novotny wrote:
> On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
>> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal Novotny wrote:
>>> Oh, one more thing I''ve discovered now. Since the codebase
for
>>> qemu-xen-unstable is looking the same like for qemu-xen-3.4-testing
and
>>> the patch is applicable without any modifications it could be
working
>>> for xen-4.1 unstable as well, unfortunately I was not able to boot 
>>> PVOPS
>>> kernel since it always ends up in kernel panic, maybe the missing
>>> drivers or something like that.
>>>
>> What kernel version? Did you use xen/stable-2.6.32.x branch from 
>> xen.git?
>
> It''s the one that''s being automatically downloaded from
git as
> linux-2.6-pvops.git. The URL is 
> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git with the 
> "fetch" being set to
"+refs/heads/*:refs/remotes/xen/*". This is the
> .git/config automatically created by `make world` in xen-unstable tree:
>
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [remote "xen"]
> url = git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> fetch = +refs/heads/*:refs/remotes/xen/*
> [branch "xen/stable-2.6.31.x"]
> remote = xen
> merge = refs/heads/xen/stable-2.6.31.x
>
> By default it''s using uhci-hcd/ehci-hcd and ohci-hcd as builtins
but I
> needed to change it to be modules since otherwise it''s being
stuck.
> I''m trying this on RHEL-5 dom0 (I''m having second
partition RHEL-5
> with upstream xen).
>> See my example .config files from:
>> http://wiki.xensource.com/xenwiki/XenParavirtOps in the 
>> "troubleshooting" section.
>
> I''ll have a look, thanks for the link.
>
>> Works on F12/F13 dom0''s.
>>
>> For el5 dom0 you might need these:
>> http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>
> Oh, ok, this may be very useful since I''m trying this on RHEL-5.
Thanks!
>
>> aka
>> CONFIG_SYSFS_DEPRECATED=y
>> CONFIG_SYSFS_DEPRECATED_V2=y
>>
>> Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y in the .config
>> because of the recently added pv-on-hvm drivers (you''ll get
build
>> failure without that option),
>> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or 
>> XEN_NETDEV_FRONTEND or XEN_FBDEV_FRONTEND needs to be =y.
>>
>
> Great! Thanks for your help Pasi! If anything I''ll let you know.
>
> Michal
>
>> -- Pasi
>>
>>
>>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>>> Oh, just one more thing that should be mentioned:
>>>>
>>>> When you want to mount an image that is set as read-only in the
domain
>>>> configuration file but you omit to set mode to read-only it
results
>>>> into I/O errors when processing the requests. Remounting as
read-only
>>>> or unmounting and remounting using the `mount /dev/*
/path/to/mount -o
>>>> ro` shall do the mounting the correct way, i.e. with no I/O
errors, so
>>>> make sure you mount those disks as read-only otherwise you can
be
>>>> getting errors like:
>>>>
>>>> end_request: I/O error, dev hdb, sector 52
>>>>
>>>> Buffer I/O error on device hdb1, logical block 1
>>>>
>>>> lost page write due to I/O error on hdb1
>>>>
>>>>
>>>> and for IDE devices you''ll be getting several
additional DeviceFault
>>>> errors since mounting the device read-write (default setting)
writes
>>>> some data onto a disk at the mount-time.
>>>>
>>>> Michal
>>>>
>>>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>>>> [Well, I did send an e-mail to the list using git but
it''s not here
>>>>> so I''m forwarding the e-mail to the list for
sure:]
>>>>>
>>>>> Hi,
>>>>> this is the patch for qemu-xen-3.4-testing to fix the
read-only
>>>>> image file handling since the image file was always treated
as
>>>>> read-write which means that all the HVM guests were able to
>>>>> write to all the disk images available in domain
configuration
>>>>> file no matter what the mode of the image was defined. This
>>>>> patch fixes this functionality to honor the O_RDONLY in the
>>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and
SCSI
>>>>> interfaces that uses it.
>>>>>
>>>>> It''s been tested on RHEL-5 with xen-3.4-testing
version of
>>>>> upstream xen with xen-3.4-testing qemu implementation.
>>>>>
>>>>> For SCSI devices the DATA PROTECT request sense has been
added
>>>>> as found at:
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>>
>>>>> file no matter what the mode of the image was defined. This
>>>>> patch fixes this functionality to honor the O_RDONLY in the
>>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and
SCSI
>>>>> interfaces that uses it.
>>>>>
>>>>> It''s been tested on RHEL-5 with xen-3.4-testing
version of
>>>>> Michal
>>>>>
>>>>> Signed-off-by: Michal Novotny<minovotn@redhat.com>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>>
>>>
>>> -- 
>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>> Virtualization Team (xen userspace), Red Hat
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>
>

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

You need to bring your qemu repo up to date. Throw it away, or go into it
and ''git pull -a''.

 -- Keir

On 04/06/2010 14:00, "Michal Novotny" <minovotn@redhat.com>
wrote:
> Well, now the kernel is booting but when I''m trying to recompile
tools
> and stubdom images it''s not OK returning those errors:
> 
> ...
> qemu successfuly configured for Xen qemu-dm build
> make -C ioemu-dir install
> === PCI passthrough capability has been enabled ==> make[3]: Entering
directory
> `/home2/shared/xen-unstable.hg/tools/ioemu-remote''
> === PCI passthrough capability has been enabled ==> === PCI passthrough
capability has been enabled ==> make[4]: Entering directory
> `/home2/shared/xen-unstable.hg/tools/ioemu-remote/i386-dm''
> CC i386-dm/vl.o
> /home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c: In function Œmain¹:
> /home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c:5729: warning:
> implicit declaration of function Œdma_helper_init¹
> /home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c:5731: error: too few
> arguments to function Œxc_interface_open¹
> make[4]: *** [vl.o] Error 1
> make[4]: Leaving directory
> `/home2/shared/xen-unstable.hg/tools/ioemu-remote/i386-dm''
> make[3]: *** [subdir-i386-dm] Error 2
> make[3]: Leaving directory
> `/home2/shared/xen-unstable.hg/tools/ioemu-remote''
> make[2]: *** [subdir-install-ioemu-dir] Error 2
> make[2]: Leaving directory `/home2/shared/xen-unstable.hg/tools''
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/home2/shared/xen-unstable.hg/tools''
> make: *** [install-tools] Error 2
> #
> 
> The command I used for compilation is `make install-xen && make
> install-tools && make install-stubdom && make install-docs`
on the
> latest updated xen-unstable staging mercurial tree so I need to
> investigate this further. Nevertheless, the dom0 2.6.31.13 is booting on
> RHEL-5 which is good. That links you gave me Pasi helped, thanks! Now I
> need to resolve those tools issues.
> 
> Michal
> 
> On 06/04/2010 12:57 PM, Michal Novotny wrote:
>> On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
>>> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal Novotny wrote:
>>>> Oh, one more thing I''ve discovered now. Since the
codebase for
>>>> qemu-xen-unstable is looking the same like for
qemu-xen-3.4-testing and
>>>> the patch is applicable without any modifications it could be
working
>>>> for xen-4.1 unstable as well, unfortunately I was not able to
boot
>>>> PVOPS
>>>> kernel since it always ends up in kernel panic, maybe the
missing
>>>> drivers or something like that.
>>>> 
>>> What kernel version? Did you use xen/stable-2.6.32.x branch from
>>> xen.git?
>> 
>> It''s the one that''s being automatically downloaded
from git as
>> linux-2.6-pvops.git. The URL is
>> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git with the
>> "fetch" being set to
"+refs/heads/*:refs/remotes/xen/*". This is the
>> .git/config automatically created by `make world` in xen-unstable tree:
>> 
>> [core]
>> repositoryformatversion = 0
>> filemode = true
>> bare = false
>> logallrefupdates = true
>> [remote "xen"]
>> url = git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
>> fetch = +refs/heads/*:refs/remotes/xen/*
>> [branch "xen/stable-2.6.31.x"]
>> remote = xen
>> merge = refs/heads/xen/stable-2.6.31.x
>> 
>> By default it''s using uhci-hcd/ehci-hcd and ohci-hcd as
builtins but I
>> needed to change it to be modules since otherwise it''s being
stuck.
>> I''m trying this on RHEL-5 dom0 (I''m having second
partition RHEL-5
>> with upstream xen).
>>> See my example .config files from:
>>> http://wiki.xensource.com/xenwiki/XenParavirtOps in the
>>> "troubleshooting" section.
>> 
>> I''ll have a look, thanks for the link.
>> 
>>> Works on F12/F13 dom0''s.
>>> 
>>> For el5 dom0 you might need these:
>>> http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>> 
>> Oh, ok, this may be very useful since I''m trying this on
RHEL-5. Thanks!
>> 
>>> aka
>>> CONFIG_SYSFS_DEPRECATED=y
>>> CONFIG_SYSFS_DEPRECATED_V2=y
>>> 
>>> Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y in the
.config
>>> because of the recently added pv-on-hvm drivers (you''ll
get build
>>> failure without that option),
>>> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or
>>> XEN_NETDEV_FRONTEND or XEN_FBDEV_FRONTEND needs to be =y.
>>> 
>> 
>> Great! Thanks for your help Pasi! If anything I''ll let you
know.
>> 
>> Michal
>> 
>>> -- Pasi
>>> 
>>> 
>>>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>>>> Oh, just one more thing that should be mentioned:
>>>>> 
>>>>> When you want to mount an image that is set as read-only in
the domain
>>>>> configuration file but you omit to set mode to read-only it
results
>>>>> into I/O errors when processing the requests. Remounting as
read-only
>>>>> or unmounting and remounting using the `mount /dev/*
/path/to/mount -o
>>>>> ro` shall do the mounting the correct way, i.e. with no I/O
errors, so
>>>>> make sure you mount those disks as read-only otherwise you
can be
>>>>> getting errors like:
>>>>> 
>>>>> end_request: I/O error, dev hdb, sector 52
>>>>> 
>>>>> Buffer I/O error on device hdb1, logical block 1
>>>>> 
>>>>> lost page write due to I/O error on hdb1
>>>>> 
>>>>> 
>>>>> and for IDE devices you''ll be getting several
additional DeviceFault
>>>>> errors since mounting the device read-write (default
setting) writes
>>>>> some data onto a disk at the mount-time.
>>>>> 
>>>>> Michal
>>>>> 
>>>>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>>>>> [Well, I did send an e-mail to the list using git but
it''s not here
>>>>>> so I''m forwarding the e-mail to the list for
sure:]
>>>>>> 
>>>>>> Hi,
>>>>>> this is the patch for qemu-xen-3.4-testing to fix the
read-only
>>>>>> image file handling since the image file was always
treated as
>>>>>> read-write which means that all the HVM guests were
able to
>>>>>> write to all the disk images available in domain
configuration
>>>>>> file no matter what the mode of the image was defined.
This
>>>>>> patch fixes this functionality to honor the O_RDONLY in
the
>>>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE
and SCSI
>>>>>> interfaces that uses it.
>>>>>> 
>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>> upstream xen with xen-3.4-testing qemu implementation.
>>>>>> 
>>>>>> For SCSI devices the DATA PROTECT request sense has
been added
>>>>>> as found at:
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>>> 
>>>>>> file no matter what the mode of the image was defined.
This
>>>>>> patch fixes this functionality to honor the O_RDONLY in
the
>>>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE
and SCSI
>>>>>> interfaces that uses it.
>>>>>> 
>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>> Michal
>>>>>> 
>>>>>> Signed-off-by: Michal
Novotny<minovotn@redhat.com>
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>>>> 
>>>> 
>>>> -- 
>>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>>> Virtualization Team (xen userspace), Red Hat
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>> 
>> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Jun 04, 2010 at 03:00:59PM +0200, Michal Novotny
wrote:
> Well, now the kernel is booting but when I''m trying to recompile
tools
> and stubdom images it''s not OK returning those errors:
>
> ...
> qemu successfuly configured for Xen qemu-dm build
> make -C ioemu-dir install
> === PCI passthrough capability has been enabled ==> make[3]: Entering
directory
> `/home2/shared/xen-unstable.hg/tools/ioemu-remote''
> === PCI passthrough capability has been enabled ==> === PCI passthrough
capability has been enabled ==> make[4]: Entering directory
> `/home2/shared/xen-unstable.hg/tools/ioemu-remote/i386-dm''
> CC i386-dm/vl.o
> /home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c: In function ?main?:
> /home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c:5729: warning:  
> implicit declaration of function ?dma_helper_init?
> /home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c:5731: error: too few  
> arguments to function ?xc_interface_open?
> make[4]: *** [vl.o] Error 1
> make[4]: Leaving directory  
> `/home2/shared/xen-unstable.hg/tools/ioemu-remote/i386-dm''
> make[3]: *** [subdir-i386-dm] Error 2
> make[3]: Leaving directory  
> `/home2/shared/xen-unstable.hg/tools/ioemu-remote''
> make[2]: *** [subdir-install-ioemu-dir] Error 2
> make[2]: Leaving directory `/home2/shared/xen-unstable.hg/tools''
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory `/home2/shared/xen-unstable.hg/tools''
> make: *** [install-tools] Error 2
> #
>
> The command I used for compilation is `make install-xen && make  
> install-tools && make install-stubdom && make install-docs`
on the
> latest updated xen-unstable staging mercurial tree so I need to  
> investigate this further. Nevertheless, the dom0 2.6.31.13 is booting on  
> RHEL-5 which is good. That links you gave me Pasi helped, thanks! Now I  
> need to resolve those tools issues.
>
You could try compiling the latest xen-4.0-testing.hg .. just to see if that
works.
Then it''d be a bug/regression in xen-unstable.

Good to hear the kernel works! 2.6.31 based tree is the default (still),
but 2.6.32 based tree is the ''long term supported'' tree..

-- Pasi
> Michal
>
> On 06/04/2010 12:57 PM, Michal Novotny wrote:
>> On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
>>> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal Novotny wrote:
>>>> Oh, one more thing I''ve discovered now. Since the
codebase for
>>>> qemu-xen-unstable is looking the same like for
qemu-xen-3.4-testing and
>>>> the patch is applicable without any modifications it could be
working
>>>> for xen-4.1 unstable as well, unfortunately I was not able to
boot
>>>> PVOPS
>>>> kernel since it always ends up in kernel panic, maybe the
missing
>>>> drivers or something like that.
>>>>
>>> What kernel version? Did you use xen/stable-2.6.32.x branch from  
>>> xen.git?
>>
>> It''s the one that''s being automatically downloaded
from git as
>> linux-2.6-pvops.git. The URL is  
>> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git with the  
>> "fetch" being set to
"+refs/heads/*:refs/remotes/xen/*". This is the
>> .git/config automatically created by `make world` in xen-unstable tree:
>>
>> [core]
>> repositoryformatversion = 0
>> filemode = true
>> bare = false
>> logallrefupdates = true
>> [remote "xen"]
>> url = git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
>> fetch = +refs/heads/*:refs/remotes/xen/*
>> [branch "xen/stable-2.6.31.x"]
>> remote = xen
>> merge = refs/heads/xen/stable-2.6.31.x
>>
>> By default it''s using uhci-hcd/ehci-hcd and ohci-hcd as
builtins but I
>> needed to change it to be modules since otherwise it''s being
stuck.
>> I''m trying this on RHEL-5 dom0 (I''m having second
partition RHEL-5
>> with upstream xen).
>>> See my example .config files from:
>>> http://wiki.xensource.com/xenwiki/XenParavirtOps in the  
>>> "troubleshooting" section.
>>
>> I''ll have a look, thanks for the link.
>>
>>> Works on F12/F13 dom0''s.
>>>
>>> For el5 dom0 you might need these:
>>> http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>>
>> Oh, ok, this may be very useful since I''m trying this on
RHEL-5. Thanks!
>>
>>> aka
>>> CONFIG_SYSFS_DEPRECATED=y
>>> CONFIG_SYSFS_DEPRECATED_V2=y
>>>
>>> Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y in the
.config
>>> because of the recently added pv-on-hvm drivers (you''ll
get build
>>> failure without that option),
>>> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or  
>>> XEN_NETDEV_FRONTEND or XEN_FBDEV_FRONTEND needs to be =y.
>>>
>>
>> Great! Thanks for your help Pasi! If anything I''ll let you
know.
>>
>> Michal
>>
>>> -- Pasi
>>>
>>>
>>>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>>>> Oh, just one more thing that should be mentioned:
>>>>>
>>>>> When you want to mount an image that is set as read-only in
the domain
>>>>> configuration file but you omit to set mode to read-only it
results
>>>>> into I/O errors when processing the requests. Remounting as
read-only
>>>>> or unmounting and remounting using the `mount /dev/*
/path/to/mount -o
>>>>> ro` shall do the mounting the correct way, i.e. with no I/O
errors, so
>>>>> make sure you mount those disks as read-only otherwise you
can be
>>>>> getting errors like:
>>>>>
>>>>> end_request: I/O error, dev hdb, sector 52
>>>>>
>>>>> Buffer I/O error on device hdb1, logical block 1
>>>>>
>>>>> lost page write due to I/O error on hdb1
>>>>>
>>>>>
>>>>> and for IDE devices you''ll be getting several
additional DeviceFault
>>>>> errors since mounting the device read-write (default
setting) writes
>>>>> some data onto a disk at the mount-time.
>>>>>
>>>>> Michal
>>>>>
>>>>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>>>>> [Well, I did send an e-mail to the list using git but
it''s not here
>>>>>> so I''m forwarding the e-mail to the list for
sure:]
>>>>>>
>>>>>> Hi,
>>>>>> this is the patch for qemu-xen-3.4-testing to fix the
read-only
>>>>>> image file handling since the image file was always
treated as
>>>>>> read-write which means that all the HVM guests were
able to
>>>>>> write to all the disk images available in domain
configuration
>>>>>> file no matter what the mode of the image was defined.
This
>>>>>> patch fixes this functionality to honor the O_RDONLY in
the
>>>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE
and SCSI
>>>>>> interfaces that uses it.
>>>>>>
>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>> upstream xen with xen-3.4-testing qemu implementation.
>>>>>>
>>>>>> For SCSI devices the DATA PROTECT request sense has
been added
>>>>>> as found at:
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>>>
>>>>>> file no matter what the mode of the image was defined.
This
>>>>>> patch fixes this functionality to honor the O_RDONLY in
the
>>>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE
and SCSI
>>>>>> interfaces that uses it.
>>>>>>
>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>> Michal
>>>>>>
>>>>>> Signed-off-by: Michal
Novotny<minovotn@redhat.com>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>>>>
>>>>
>>>> -- 
>>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>>> Virtualization Team (xen userspace), Red Hat
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>
>>
>
>
> -- 
> Michal Novotny<minovotn@redhat.com>, RHCE
> Virtualization Team (xen userspace), Red Hat
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/04/2010 03:16 PM, Keir Fraser wrote:
> On 04/06/2010 14:13, "Michal Novotny"<minovotn@redhat.com> 
wrote:
>
>    
>> Keir,
>> I tried it and it''s already up to date:
>>
>> $ git pull -a
>> Already up-to-date. Yeeah!
>> $
>>      
> Don''t believe you, or it''s not the one that''s
actually being built. :-) If
> you grep in the tree for xc_interface_open() you should see it is correctly
> passing three args now.
Sorry, my bad, something was wrong with my git tree so I deleted it and 
pulled again.

Thanks,
Michal
> And if it is, then that will build okay. If it''s not
> passing three args, the tree is stale.
>
>   -- Keir
>
>    
>> -- Michal
>>
>> On 06/04/2010 03:11 PM, Keir Fraser wrote:
>>      
>>> You need to bring your qemu repo up to date. Throw it away, or go
into it
>>> and ''git pull -a''.
>>>
>>>    -- Keir
>>>
>>> On 04/06/2010 14:00, "Michal
Novotny"<minovotn@redhat.com>   wrote:
>>>
>>>
>>>        
>>>> Well, now the kernel is booting but when I''m trying to
recompile tools
>>>> and stubdom images it''s not OK returning those errors:
>>>>
>>>> ...
>>>> qemu successfuly configured for Xen qemu-dm build
>>>> make -C ioemu-dir install
>>>> === PCI passthrough capability has been enabled
==>>>> make[3]: Entering directory
>>>> `/home2/shared/xen-unstable.hg/tools/ioemu-remote''
>>>> === PCI passthrough capability has been enabled
==>>>> === PCI passthrough capability has been enabled
==>>>> make[4]: Entering directory
>>>>
`/home2/shared/xen-unstable.hg/tools/ioemu-remote/i386-dm''
>>>> CC i386-dm/vl.o
>>>> /home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c: In function
Œmain¹:
>>>> /home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c:5729:
warning:
>>>> implicit declaration of function Œdma_helper_init¹
>>>> /home2/shared/xen-unstable.hg/tools/ioemu-dir/vl.c:5731: error:
too few
>>>> arguments to function Œxc_interface_open¹
>>>> make[4]: *** [vl.o] Error 1
>>>> make[4]: Leaving directory
>>>>
`/home2/shared/xen-unstable.hg/tools/ioemu-remote/i386-dm''
>>>> make[3]: *** [subdir-i386-dm] Error 2
>>>> make[3]: Leaving directory
>>>> `/home2/shared/xen-unstable.hg/tools/ioemu-remote''
>>>> make[2]: *** [subdir-install-ioemu-dir] Error 2
>>>> make[2]: Leaving directory
`/home2/shared/xen-unstable.hg/tools''
>>>> make[1]: *** [subdirs-install] Error 2
>>>> make[1]: Leaving directory
`/home2/shared/xen-unstable.hg/tools''
>>>> make: *** [install-tools] Error 2
>>>> #
>>>>
>>>> The command I used for compilation is `make
install-xen&&   make
>>>> install-tools&&   make install-stubdom&&   make
install-docs` on the
>>>> latest updated xen-unstable staging mercurial tree so I need to
>>>> investigate this further. Nevertheless, the dom0 2.6.31.13 is
booting on
>>>> RHEL-5 which is good. That links you gave me Pasi helped,
thanks! Now I
>>>> need to resolve those tools issues.
>>>>
>>>> Michal
>>>>
>>>> On 06/04/2010 12:57 PM, Michal Novotny wrote:
>>>>
>>>>          
>>>>> On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
>>>>>
>>>>>            
>>>>>> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal
Novotny wrote:
>>>>>>
>>>>>>              
>>>>>>> Oh, one more thing I''ve discovered now.
Since the codebase for
>>>>>>> qemu-xen-unstable is looking the same like for
qemu-xen-3.4-testing and
>>>>>>> the patch is applicable without any modifications
it could be working
>>>>>>> for xen-4.1 unstable as well, unfortunately I was
not able to boot
>>>>>>> PVOPS
>>>>>>> kernel since it always ends up in kernel panic,
maybe the missing
>>>>>>> drivers or something like that.
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> What kernel version? Did you use xen/stable-2.6.32.x
branch from
>>>>>> xen.git?
>>>>>>
>>>>>>              
>>>>> It''s the one that''s being automatically
downloaded from git as
>>>>> linux-2.6-pvops.git. The URL is
>>>>>
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git with the
>>>>> "fetch" being set to
"+refs/heads/*:refs/remotes/xen/*". This is the
>>>>> .git/config automatically created by `make world` in
xen-unstable tree:
>>>>>
>>>>> [core]
>>>>> repositoryformatversion = 0
>>>>> filemode = true
>>>>> bare = false
>>>>> logallrefupdates = true
>>>>> [remote "xen"]
>>>>> url =
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
>>>>> fetch = +refs/heads/*:refs/remotes/xen/*
>>>>> [branch "xen/stable-2.6.31.x"]
>>>>> remote = xen
>>>>> merge = refs/heads/xen/stable-2.6.31.x
>>>>>
>>>>> By default it''s using uhci-hcd/ehci-hcd and
ohci-hcd as builtins but I
>>>>> needed to change it to be modules since otherwise
it''s being stuck.
>>>>> I''m trying this on RHEL-5 dom0 (I''m
having second partition RHEL-5
>>>>> with upstream xen).
>>>>>
>>>>>            
>>>>>> See my example .config files from:
>>>>>> http://wiki.xensource.com/xenwiki/XenParavirtOps in the
>>>>>> "troubleshooting" section.
>>>>>>
>>>>>>              
>>>>> I''ll have a look, thanks for the link.
>>>>>
>>>>>
>>>>>            
>>>>>> Works on F12/F13 dom0''s.
>>>>>>
>>>>>> For el5 dom0 you might need these:
>>>>>>
http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>>>>>>
>>>>>>              
>>>>> Oh, ok, this may be very useful since I''m trying
this on RHEL-5. Thanks!
>>>>>
>>>>>
>>>>>            
>>>>>> aka
>>>>>> CONFIG_SYSFS_DEPRECATED=y
>>>>>> CONFIG_SYSFS_DEPRECATED_V2=y
>>>>>>
>>>>>> Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y
in the .config
>>>>>> because of the recently added pv-on-hvm drivers
(you''ll get build
>>>>>> failure without that option),
>>>>>> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or
>>>>>> XEN_NETDEV_FRONTEND or XEN_FBDEV_FRONTEND needs to be
=y.
>>>>>>
>>>>>>
>>>>>>              
>>>>> Great! Thanks for your help Pasi! If anything I''ll
let you know.
>>>>>
>>>>> Michal
>>>>>
>>>>>
>>>>>            
>>>>>> -- Pasi
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>>>>>>
>>>>>>>                
>>>>>>>> Oh, just one more thing that should be
mentioned:
>>>>>>>>
>>>>>>>> When you want to mount an image that is set as
read-only in the domain
>>>>>>>> configuration file but you omit to set mode to
read-only it results
>>>>>>>> into I/O errors when processing the requests.
Remounting as read-only
>>>>>>>> or unmounting and remounting using the `mount
/dev/* /path/to/mount -o
>>>>>>>> ro` shall do the mounting the correct way, i.e.
with no I/O errors, so
>>>>>>>> make sure you mount those disks as read-only
otherwise you can be
>>>>>>>> getting errors like:
>>>>>>>>
>>>>>>>> end_request: I/O error, dev hdb, sector 52
>>>>>>>>
>>>>>>>> Buffer I/O error on device hdb1, logical block
1
>>>>>>>>
>>>>>>>> lost page write due to I/O error on hdb1
>>>>>>>>
>>>>>>>>
>>>>>>>> and for IDE devices you''ll be getting
several additional DeviceFault
>>>>>>>> errors since mounting the device read-write
(default setting) writes
>>>>>>>> some data onto a disk at the mount-time.
>>>>>>>>
>>>>>>>> Michal
>>>>>>>>
>>>>>>>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> [Well, I did send an e-mail to the list
using git but it''s not here
>>>>>>>>> so I''m forwarding the e-mail to
the list for sure:]
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> this is the patch for qemu-xen-3.4-testing
to fix the read-only
>>>>>>>>> image file handling since the image file
was always treated as
>>>>>>>>> read-write which means that all the HVM
guests were able to
>>>>>>>>> write to all the disk images available in
domain configuration
>>>>>>>>> file no matter what the mode of the image
was defined. This
>>>>>>>>> patch fixes this functionality to honor the
O_RDONLY in the
>>>>>>>>> BDRV_O_ACCESS flag in block.c and also
fixes the IDE and SCSI
>>>>>>>>> interfaces that uses it.
>>>>>>>>>
>>>>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>>>>> upstream xen with xen-3.4-testing qemu
implementation.
>>>>>>>>>
>>>>>>>>> For SCSI devices the DATA PROTECT request
sense has been added
>>>>>>>>> as found at:
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>>>>>>
>>>>>>>>> file no matter what the mode of the image
was defined. This
>>>>>>>>> patch fixes this functionality to honor the
O_RDONLY in the
>>>>>>>>> BDRV_O_ACCESS flag in block.c and also
fixes the IDE and SCSI
>>>>>>>>> interfaces that uses it.
>>>>>>>>>
>>>>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>>>>> Michal
>>>>>>>>>
>>>>>>>>> Signed-off-by: Michal
Novotny<minovotn@redhat.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
_______________________________________________
>>>>>>>>> Xen-devel mailing list
>>>>>>>>> Xen-devel@lists.xensource.com
>>>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>>
>>>>>>>>                  
>>>>>>> -- 
>>>>>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>>>>>> Virtualization Team (xen userspace), Red Hat
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xen-devel mailing list
>>>>>>> Xen-devel@lists.xensource.com
>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>
>>>>>>>                
>>>>>
>>>>>            
>>>>
>>>>          
>>>
>>>        
>>      
>
>    

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Well, I''m still having some tools issues, mainly:

[2010-06-07 15:19:24 5346] INFO (XendNetwork:114) Not recreating missing 
unmanaged network xenbr0
[2010-06-07 15:19:25 5346] DEBUG (XendCPUPool:747) recreate_active_pools
[2010-06-07 15:19:26 5346] ERROR (SrvDaemon:349) Exception starting xend 
((111, ''Connection refused''))
Traceback (most recent call last):
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDaemon.py",
line
341, in run
     servers = SrvServer.create()
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvServer.py",
line
258, in create
     root.putChild(''xend'', SrvRoot())
   File
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvRoot.py",
line 40, in __init__
     self.get(name)
   File "/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line
84,
in get
     val = val.getobj()
   File "/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line
52,
in getobj
     self.obj = klassobj()
   File
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvNode.py",
line 30, in __init__
     self.xn = XendNode.instance()
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py",
line
1176, in instance
     inst = XendNode()
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py",
line
163, in __init__
     self._init_cpu_pools()
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py",
line
377, in _init_cpu_pools
     XendCPUPool.recreate_active_pools()
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendCPUPool.py", 
line 754, in recreate_active_pools
     uuid = xstransact.Read(path, ''uuid'')
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py", 
line 307, in Read
     return complete(path, lambda t: t.read(*args))
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py", 
line 361, in complete
     t = xstransact(path)
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py", 
line 29, in __init__
     self.transaction = xshandle().transaction_start()
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xsutil.py", line
18, in xshandle
     xs_handle = xen.lowlevel.xs.xs()
Error: (111, ''Connection refused'')

Any guess what may be going wrong? Booted grub entry:

title Red Hat Enterprise Linux Server (2.6.31.13-xen HV, nolog)
         root (hd1,6)
         kernel /xen-4.1-unstable.gz
         module /vmlinuz-2.6.31.13 ro root=LABEL=/rhel2 rhgb quiet selinux=0
         module /initrd-2.6.31.13.img

Mount is having `xenfs on /proc/xen type xenfs (rw)`. Any guess what may 
be going wrong?

Thanks,
Michal

On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal Novotny wrote:
>    
>> Oh, one more thing I''ve discovered now. Since the codebase for
>> qemu-xen-unstable is looking the same like for qemu-xen-3.4-testing and
>> the patch is applicable without any modifications it could be working
>> for xen-4.1 unstable as well, unfortunately I was not able to boot
PVOPS
>> kernel since it always ends up in kernel panic, maybe the missing
>> drivers or something like that.
>>
>>      
> What kernel version? Did you use xen/stable-2.6.32.x branch from xen.git?
>
> See my example .config files from:
> http://wiki.xensource.com/xenwiki/XenParavirtOps in the
"troubleshooting" section.
>
> Works on F12/F13 dom0''s.
>
> For el5 dom0 you might need these:
> http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>
> aka
> CONFIG_SYSFS_DEPRECATED=y
> CONFIG_SYSFS_DEPRECATED_V2=y
>
> Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y in the .config
> because of the recently added pv-on-hvm drivers (you''ll get build
failure without that option),
> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or XEN_NETDEV_FRONTEND
or XEN_FBDEV_FRONTEND needs to be =y.
>
> -- Pasi
>
>
>    
>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>      
>>> Oh, just one more thing that should be mentioned:
>>>
>>> When you want to mount an image that is set as read-only in the
domain
>>> configuration file but you omit to set mode to read-only it results
>>> into I/O errors when processing the requests. Remounting as
read-only
>>> or unmounting and remounting using the `mount /dev/* /path/to/mount
-o
>>> ro` shall do the mounting the correct way, i.e. with no I/O errors,
so
>>> make sure you mount those disks as read-only otherwise you can be
>>> getting errors like:
>>>
>>> end_request: I/O error, dev hdb, sector 52
>>>
>>> Buffer I/O error on device hdb1, logical block 1
>>>
>>> lost page write due to I/O error on hdb1
>>>
>>>
>>> and for IDE devices you''ll be getting several additional
DeviceFault
>>> errors since mounting the device read-write (default setting)
writes
>>> some data onto a disk at the mount-time.
>>>
>>> Michal
>>>
>>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>>        
>>>> [Well, I did send an e-mail to the list using git but
it''s not here
>>>> so I''m forwarding the e-mail to the list for sure:]
>>>>
>>>> Hi,
>>>> this is the patch for qemu-xen-3.4-testing to fix the read-only
>>>> image file handling since the image file was always treated as
>>>> read-write which means that all the HVM guests were able to
>>>> write to all the disk images available in domain configuration
>>>> file no matter what the mode of the image was defined. This
>>>> patch fixes this functionality to honor the O_RDONLY in the
>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI
>>>> interfaces that uses it.
>>>>
>>>> It''s been tested on RHEL-5 with xen-3.4-testing
version of
>>>> upstream xen with xen-3.4-testing qemu implementation.
>>>>
>>>> For SCSI devices the DATA PROTECT request sense has been added
>>>> as found at:
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>
>>>> file no matter what the mode of the image was defined. This
>>>> patch fixes this functionality to honor the O_RDONLY in the
>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and SCSI
>>>> interfaces that uses it.
>>>>
>>>> It''s been tested on RHEL-5 with xen-3.4-testing
version of
>>>> Michal
>>>>
>>>> Signed-off-by: Michal Novotny<minovotn@redhat.com>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>>          
>>>
>>>        
>>
>> -- 
>> Michal Novotny<minovotn@redhat.com>, RHCE
>> Virtualization Team (xen userspace), Red Hat
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>      

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 07/06/2010 12:21, "Michal Novotny" <minovotn@redhat.com>
wrote:
> "/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xsutil.py",
line
> 18, in xshandle
>      xs_handle = xen.lowlevel.xs.xs()
> Error: (111, ''Connection refused'')
> 
> Any guess what may be going wrong?
Xenstored not running, or refusing connections for some other reason?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Jun 07, 2010 at 01:21:21PM +0200, Michal Novotny
wrote:
> Well, I''m still having some tools issues, mainly:
>
> Error: (111, ''Connection refused'')
>
> Any guess what may be going wrong? Booted grub entry:
>
> title Red Hat Enterprise Linux Server (2.6.31.13-xen HV, nolog)
>         root (hd1,6)
>         kernel /xen-4.1-unstable.gz
>         module /vmlinuz-2.6.31.13 ro root=LABEL=/rhel2 rhgb quiet selinux=0
>         module /initrd-2.6.31.13.img
>
> Mount is having `xenfs on /proc/xen type xenfs (rw)`. Any guess what may  
> be going wrong?
>

Do you have xen-evtchn driver loaded? 


-- Pasi

> Thanks,
> Michal
>
> On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
>> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal Novotny wrote:
>>    
>>> Oh, one more thing I''ve discovered now. Since the codebase
for
>>> qemu-xen-unstable is looking the same like for qemu-xen-3.4-testing
and
>>> the patch is applicable without any modifications it could be
working
>>> for xen-4.1 unstable as well, unfortunately I was not able to boot
PVOPS
>>> kernel since it always ends up in kernel panic, maybe the missing
>>> drivers or something like that.
>>>
>>>      
>> What kernel version? Did you use xen/stable-2.6.32.x branch from
xen.git?
>>
>> See my example .config files from:
>> http://wiki.xensource.com/xenwiki/XenParavirtOps in the
"troubleshooting" section.
>>
>> Works on F12/F13 dom0''s.
>>
>> For el5 dom0 you might need these:
>> http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>>
>> aka
>> CONFIG_SYSFS_DEPRECATED=y
>> CONFIG_SYSFS_DEPRECATED_V2=y
>>
>> Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y in the .config
>> because of the recently added pv-on-hvm drivers (you''ll get
build failure without that option),
>> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or
XEN_NETDEV_FRONTEND or XEN_FBDEV_FRONTEND needs to be =y.
>>
>> -- Pasi
>>
>>
>>    
>>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>>      
>>>> Oh, just one more thing that should be mentioned:
>>>>
>>>> When you want to mount an image that is set as read-only in the
domain
>>>> configuration file but you omit to set mode to read-only it
results
>>>> into I/O errors when processing the requests. Remounting as
read-only
>>>> or unmounting and remounting using the `mount /dev/*
/path/to/mount -o
>>>> ro` shall do the mounting the correct way, i.e. with no I/O
errors, so
>>>> make sure you mount those disks as read-only otherwise you can
be
>>>> getting errors like:
>>>>
>>>> end_request: I/O error, dev hdb, sector 52
>>>>
>>>> Buffer I/O error on device hdb1, logical block 1
>>>>
>>>> lost page write due to I/O error on hdb1
>>>>
>>>>
>>>> and for IDE devices you''ll be getting several
additional DeviceFault
>>>> errors since mounting the device read-write (default setting)
writes
>>>> some data onto a disk at the mount-time.
>>>>
>>>> Michal
>>>>
>>>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>>>        
>>>>> [Well, I did send an e-mail to the list using git but
it''s not here
>>>>> so I''m forwarding the e-mail to the list for
sure:]
>>>>>
>>>>> Hi,
>>>>> this is the patch for qemu-xen-3.4-testing to fix the
read-only
>>>>> image file handling since the image file was always treated
as
>>>>> read-write which means that all the HVM guests were able to
>>>>> write to all the disk images available in domain
configuration
>>>>> file no matter what the mode of the image was defined. This
>>>>> patch fixes this functionality to honor the O_RDONLY in the
>>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and
SCSI
>>>>> interfaces that uses it.
>>>>>
>>>>> It''s been tested on RHEL-5 with xen-3.4-testing
version of
>>>>> upstream xen with xen-3.4-testing qemu implementation.
>>>>>
>>>>> For SCSI devices the DATA PROTECT request sense has been
added
>>>>> as found at:
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>>
>>>>> file no matter what the mode of the image was defined. This
>>>>> patch fixes this functionality to honor the O_RDONLY in the
>>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE and
SCSI
>>>>> interfaces that uses it.
>>>>>
>>>>> It''s been tested on RHEL-5 with xen-3.4-testing
version of
>>>>> Michal
>>>>>
>>>>> Signed-off-by: Michal Novotny<minovotn@redhat.com>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>>>          
>>>>
>>>>        
>>>
>>> -- 
>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>> Virtualization Team (xen userspace), Red Hat
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>      
>
>
> -- 
> Michal Novotny<minovotn@redhat.com>, RHCE
> Virtualization Team (xen userspace), Red Hat
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 01:39 PM, Keir Fraser wrote:
> On 07/06/2010 12:21, "Michal Novotny"<minovotn@redhat.com> 
wrote:
>
>    
>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xsutil.py", line
>> 18, in xshandle
>>       xs_handle = xen.lowlevel.xs.xs()
>> Error: (111, ''Connection refused'')
>>
>> Any guess what may be going wrong?
>>      
> Xenstored not running, or refusing connections for some other reason?
>
>   -- Keir
>
>
>    
Not running and refusing to run: FATAL: Failed to open evtchn device: No 
such file or directory

Michal

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 01:45 PM, Pasi Kärkkäinen wrote:
> On Mon, Jun 07, 2010 at 01:21:21PM +0200, Michal Novotny wrote:
>    
>> Well, I''m still having some tools issues, mainly:
>>
>> Error: (111, ''Connection refused'')
>>
>> Any guess what may be going wrong? Booted grub entry:
>>
>> title Red Hat Enterprise Linux Server (2.6.31.13-xen HV, nolog)
>>          root (hd1,6)
>>          kernel /xen-4.1-unstable.gz
>>          module /vmlinuz-2.6.31.13 ro root=LABEL=/rhel2 rhgb quiet
selinux=0
>>          module /initrd-2.6.31.13.img
>>
>> Mount is having `xenfs on /proc/xen type xenfs (rw)`. Any guess what
may
>> be going wrong?
>>
>>      
>
> Do you have xen-evtchn driver loaded?
>
>
> -- Pasi
>
>    
Well, no, and doesn''t seem to be installed/probed:

# modprobe xen-evtchn
# lsmod | grep xen-evtchn
#

So there''s the problem :(

Michal
>    
>> Thanks,
>> Michal
>>
>> On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
>>      
>>> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal Novotny wrote:
>>>
>>>        
>>>> Oh, one more thing I''ve discovered now. Since the
codebase for
>>>> qemu-xen-unstable is looking the same like for
qemu-xen-3.4-testing and
>>>> the patch is applicable without any modifications it could be
working
>>>> for xen-4.1 unstable as well, unfortunately I was not able to
boot PVOPS
>>>> kernel since it always ends up in kernel panic, maybe the
missing
>>>> drivers or something like that.
>>>>
>>>>
>>>>          
>>> What kernel version? Did you use xen/stable-2.6.32.x branch from
xen.git?
>>>
>>> See my example .config files from:
>>> http://wiki.xensource.com/xenwiki/XenParavirtOps in the
"troubleshooting" section.
>>>
>>> Works on F12/F13 dom0''s.
>>>
>>> For el5 dom0 you might need these:
>>> http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>>>
>>> aka
>>> CONFIG_SYSFS_DEPRECATED=y
>>> CONFIG_SYSFS_DEPRECATED_V2=y
>>>
>>> Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y in the
.config
>>> because of the recently added pv-on-hvm drivers (you''ll
get build failure without that option),
>>> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or
XEN_NETDEV_FRONTEND or XEN_FBDEV_FRONTEND needs to be =y.
>>>
>>> -- Pasi
>>>
>>>
>>>
>>>        
>>>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>>>
>>>>          
>>>>> Oh, just one more thing that should be mentioned:
>>>>>
>>>>> When you want to mount an image that is set as read-only in
the domain
>>>>> configuration file but you omit to set mode to read-only it
results
>>>>> into I/O errors when processing the requests. Remounting as
read-only
>>>>> or unmounting and remounting using the `mount /dev/*
/path/to/mount -o
>>>>> ro` shall do the mounting the correct way, i.e. with no I/O
errors, so
>>>>> make sure you mount those disks as read-only otherwise you
can be
>>>>> getting errors like:
>>>>>
>>>>> end_request: I/O error, dev hdb, sector 52
>>>>>
>>>>> Buffer I/O error on device hdb1, logical block 1
>>>>>
>>>>> lost page write due to I/O error on hdb1
>>>>>
>>>>>
>>>>> and for IDE devices you''ll be getting several
additional DeviceFault
>>>>> errors since mounting the device read-write (default
setting) writes
>>>>> some data onto a disk at the mount-time.
>>>>>
>>>>> Michal
>>>>>
>>>>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>>>>
>>>>>            
>>>>>> [Well, I did send an e-mail to the list using git but
it''s not here
>>>>>> so I''m forwarding the e-mail to the list for
sure:]
>>>>>>
>>>>>> Hi,
>>>>>> this is the patch for qemu-xen-3.4-testing to fix the
read-only
>>>>>> image file handling since the image file was always
treated as
>>>>>> read-write which means that all the HVM guests were
able to
>>>>>> write to all the disk images available in domain
configuration
>>>>>> file no matter what the mode of the image was defined.
This
>>>>>> patch fixes this functionality to honor the O_RDONLY in
the
>>>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE
and SCSI
>>>>>> interfaces that uses it.
>>>>>>
>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>> upstream xen with xen-3.4-testing qemu implementation.
>>>>>>
>>>>>> For SCSI devices the DATA PROTECT request sense has
been added
>>>>>> as found at:
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>>>
>>>>>> file no matter what the mode of the image was defined.
This
>>>>>> patch fixes this functionality to honor the O_RDONLY in
the
>>>>>> BDRV_O_ACCESS flag in block.c and also fixes the IDE
and SCSI
>>>>>> interfaces that uses it.
>>>>>>
>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>> Michal
>>>>>>
>>>>>> Signed-off-by: Michal
Novotny<minovotn@redhat.com>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>>>>>
>>>>>>              
>>>>>
>>>>>            
>>>> -- 
>>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>>> Virtualization Team (xen userspace), Red Hat
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>>
>>>>          
>>
>> -- 
>> Michal Novotny<minovotn@redhat.com>, RHCE
>> Virtualization Team (xen userspace), Red Hat
>>
>>      
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 03:10 PM, Michal Novotny wrote:
> On 06/07/2010 01:45 PM, Pasi Kärkkäinen wrote:
>> On Mon, Jun 07, 2010 at 01:21:21PM +0200, Michal Novotny wrote:
>>> Well, I''m still having some tools issues, mainly:
>>>
>>> Error: (111, ''Connection refused'')
>>>
>>> Any guess what may be going wrong? Booted grub entry:
>>>
>>> title Red Hat Enterprise Linux Server (2.6.31.13-xen HV, nolog)
>>>          root (hd1,6)
>>>          kernel /xen-4.1-unstable.gz
>>>          module /vmlinuz-2.6.31.13 ro root=LABEL=/rhel2 rhgb quiet 
>>> selinux=0
>>>          module /initrd-2.6.31.13.img
>>>
>>> Mount is having `xenfs on /proc/xen type xenfs (rw)`. Any guess
what
>>> may
>>> be going wrong?
>>>
>>
>> Do you have xen-evtchn driver loaded?
>>
>>
>> -- Pasi
>>
>
> Well, no, and doesn''t seem to be installed/probed:
>
> # modprobe xen-evtchn
> # lsmod | grep xen-evtchn
> #
>
> So there''s the problem :(
>
> Michal
Oh, I''m taking this back since I found out the module is not xen-evtchn
but xen_evtchn. So yeah, I''m having it loaded in the memory now. 
However, when I do `service xend restart` the same error is here:

[2010-06-07 17:14:09 5635] INFO (SrvDaemon:227) Xend stopped due to 
signal 15.
[2010-06-07 17:14:09 6295] INFO (SrvDaemon:332) Xend Daemon started
[2010-06-07 17:14:09 6295] INFO (SrvDaemon:336) Xend changeset: Thu May 
20 17:22:15 2010 +0100 21442:a7fcf2e35d32.
[2010-06-07 17:14:09 6295] DEBUG (tcp:96) Listening on :8002
[2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating missing 
unmanaged network eth0
[2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating missing 
unmanaged network eth2
[2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating missing 
unmanaged network br0
[2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating missing 
unmanaged network xenbr0
[2010-06-07 17:14:10 6295] DEBUG (XendCPUPool:747) recreate_active_pools
[2010-06-07 17:14:10 6295] ERROR (SrvDaemon:349) Exception starting xend 
((111, ''Connection refused''))
Traceback (most recent call last):
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDaemon.py",
line
341, in run
     servers = SrvServer.create()
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvServer.py",
line
258, in create
     root.putChild(''xend'', SrvRoot())
   File
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvRoot.py",
line 40, in __init__
     self.get(name)
   File "/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line
84,
in get
     val = val.getobj()
   File "/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line
52,
in getobj
     self.obj = klassobj()
   File
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvNode.py",
line 30, in __init__
     self.xn = XendNode.instance()
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py",
line
1176, in instance
     inst = XendNode()
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py",
line
163, in __init__
     self._init_cpu_pools()
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py",
line
377, in _init_cpu_pools
     XendCPUPool.recreate_active_pools()
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendCPUPool.py", 
line 754, in recreate_active_pools
     uuid = xstransact.Read(path, ''uuid'')
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py", 
line 307, in Read
     return complete(path, lambda t: t.read(*args))
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py", 
line 361, in complete
     t = xstransact(path)
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py", 
line 29, in __init__
     self.transaction = xshandle().transaction_start()
   File 
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xsutil.py", line
18, in xshandle
     xs_handle = xen.lowlevel.xs.xs()
Error: (111, ''Connection refused'')

Any ideas?

Michal
>
>>> Thanks,
>>> Michal
>>>
>>> On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
>>>> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal Novotny wrote:
>>>>
>>>>> Oh, one more thing I''ve discovered now. Since the
codebase for
>>>>> qemu-xen-unstable is looking the same like for 
>>>>> qemu-xen-3.4-testing and
>>>>> the patch is applicable without any modifications it could
be working
>>>>> for xen-4.1 unstable as well, unfortunately I was not able
to boot
>>>>> PVOPS
>>>>> kernel since it always ends up in kernel panic, maybe the
missing
>>>>> drivers or something like that.
>>>>>
>>>>>
>>>> What kernel version? Did you use xen/stable-2.6.32.x branch
from
>>>> xen.git?
>>>>
>>>> See my example .config files from:
>>>> http://wiki.xensource.com/xenwiki/XenParavirtOps in the 
>>>> "troubleshooting" section.
>>>>
>>>> Works on F12/F13 dom0''s.
>>>>
>>>> For el5 dom0 you might need these:
>>>> http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>>>>
>>>> aka
>>>> CONFIG_SYSFS_DEPRECATED=y
>>>> CONFIG_SYSFS_DEPRECATED_V2=y
>>>>
>>>> Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y in the
.config
>>>> because of the recently added pv-on-hvm drivers
(you''ll get build
>>>> failure without that option),
>>>> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or 
>>>> XEN_NETDEV_FRONTEND or XEN_FBDEV_FRONTEND needs to be =y.
>>>>
>>>> -- Pasi
>>>>
>>>>
>>>>
>>>>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>>>>
>>>>>> Oh, just one more thing that should be mentioned:
>>>>>>
>>>>>> When you want to mount an image that is set as
read-only in the
>>>>>> domain
>>>>>> configuration file but you omit to set mode to
read-only it results
>>>>>> into I/O errors when processing the requests.
Remounting as
>>>>>> read-only
>>>>>> or unmounting and remounting using the `mount /dev/* 
>>>>>> /path/to/mount -o
>>>>>> ro` shall do the mounting the correct way, i.e. with no
I/O
>>>>>> errors, so
>>>>>> make sure you mount those disks as read-only otherwise
you can be
>>>>>> getting errors like:
>>>>>>
>>>>>> end_request: I/O error, dev hdb, sector 52
>>>>>>
>>>>>> Buffer I/O error on device hdb1, logical block 1
>>>>>>
>>>>>> lost page write due to I/O error on hdb1
>>>>>>
>>>>>>
>>>>>> and for IDE devices you''ll be getting several
additional DeviceFault
>>>>>> errors since mounting the device read-write (default
setting) writes
>>>>>> some data onto a disk at the mount-time.
>>>>>>
>>>>>> Michal
>>>>>>
>>>>>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>>>>>
>>>>>>> [Well, I did send an e-mail to the list using git
but it''s not here
>>>>>>> so I''m forwarding the e-mail to the list
for sure:]
>>>>>>>
>>>>>>> Hi,
>>>>>>> this is the patch for qemu-xen-3.4-testing to fix
the read-only
>>>>>>> image file handling since the image file was always
treated as
>>>>>>> read-write which means that all the HVM guests were
able to
>>>>>>> write to all the disk images available in domain
configuration
>>>>>>> file no matter what the mode of the image was
defined. This
>>>>>>> patch fixes this functionality to honor the
O_RDONLY in the
>>>>>>> BDRV_O_ACCESS flag in block.c and also fixes the
IDE and SCSI
>>>>>>> interfaces that uses it.
>>>>>>>
>>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>>> upstream xen with xen-3.4-testing qemu
implementation.
>>>>>>>
>>>>>>> For SCSI devices the DATA PROTECT request sense has
been added
>>>>>>> as found at: 
>>>>>>>
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>>>>
>>>>>>> file no matter what the mode of the image was
defined. This
>>>>>>> patch fixes this functionality to honor the
O_RDONLY in the
>>>>>>> BDRV_O_ACCESS flag in block.c and also fixes the
IDE and SCSI
>>>>>>> interfaces that uses it.
>>>>>>>
>>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>>> Michal
>>>>>>>
>>>>>>> Signed-off-by: Michal
Novotny<minovotn@redhat.com>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xen-devel mailing list
>>>>>>> Xen-devel@lists.xensource.com
>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>
>>>>>>
>>>>> -- 
>>>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>>>> Virtualization Team (xen userspace), Red Hat
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>>>
>>>
>>> -- 
>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>> Virtualization Team (xen userspace), Red Hat
>>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Jun 07, 2010 at 03:09:12PM +0200, Michal Novotny
wrote:
> On 06/07/2010 01:39 PM, Keir Fraser wrote:
>> On 07/06/2010 12:21, "Michal
Novotny"<minovotn@redhat.com>  wrote:
>>
>>    
>>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xsutil.py", line
>>> 18, in xshandle
>>>       xs_handle = xen.lowlevel.xs.xs()
>>> Error: (111, ''Connection refused'')
>>>
>>> Any guess what may be going wrong?
>>>      
>> Xenstored not running, or refusing connections for some other reason?
>>
>>   -- Keir
>>
>>
>>    
> Not running and refusing to run: FATAL: Failed to open evtchn device: No  
> such file or directory
>
Like I wrote in the earlier email: load xen-evtchn driver to the dom0 kernel :)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Jun 07, 2010 at 03:14:40PM +0200, Michal Novotny
wrote:
> On 06/07/2010 03:10 PM, Michal Novotny wrote:
>> On 06/07/2010 01:45 PM, Pasi Kärkkäinen wrote:
>>> On Mon, Jun 07, 2010 at 01:21:21PM +0200, Michal Novotny wrote:
>>>> Well, I''m still having some tools issues, mainly:
>>>>
>>>> Error: (111, ''Connection refused'')
>>>>
>>>> Any guess what may be going wrong? Booted grub entry:
>>>>
>>>> title Red Hat Enterprise Linux Server (2.6.31.13-xen HV, nolog)
>>>>          root (hd1,6)
>>>>          kernel /xen-4.1-unstable.gz
>>>>          module /vmlinuz-2.6.31.13 ro root=LABEL=/rhel2 rhgb
quiet
>>>> selinux=0
>>>>          module /initrd-2.6.31.13.img
>>>>
>>>> Mount is having `xenfs on /proc/xen type xenfs (rw)`. Any guess
>>>> what may
>>>> be going wrong?
>>>>
>>>
>>> Do you have xen-evtchn driver loaded?
>>>
>>>
>>> -- Pasi
>>>
>>
>> Well, no, and doesn''t seem to be installed/probed:
>>
>> # modprobe xen-evtchn
>> # lsmod | grep xen-evtchn
>> #
>>
>> So there''s the problem :(
>>
>> Michal
>
> Oh, I''m taking this back since I found out the module is not
xen-evtchn
> but xen_evtchn. So yeah, I''m having it loaded in the memory now.  
> However, when I do `service xend restart` the same error is here:
>
> [2010-06-07 17:14:09 5635] INFO (SrvDaemon:227) Xend stopped due to  
> signal 15.
> [2010-06-07 17:14:09 6295] INFO (SrvDaemon:332) Xend Daemon started
> [2010-06-07 17:14:09 6295] INFO (SrvDaemon:336) Xend changeset: Thu May  
> 20 17:22:15 2010 +0100 21442:a7fcf2e35d32.
> [2010-06-07 17:14:09 6295] DEBUG (tcp:96) Listening on :8002
> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating missing  
> unmanaged network eth0
> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating missing  
> unmanaged network eth2
> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating missing  
> unmanaged network br0
> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating missing  
> unmanaged network xenbr0
> [2010-06-07 17:14:10 6295] DEBUG (XendCPUPool:747) recreate_active_pools
> [2010-06-07 17:14:10 6295] ERROR (SrvDaemon:349) Exception starting xend  
> ((111, ''Connection refused''))
> Traceback (most recent call last):
>   File  
>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDaemon.py",
line
> 341, in run
>     servers = SrvServer.create()
>   File  
>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvServer.py",
line
> 258, in create
>     root.putChild(''xend'', SrvRoot())
>   File
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvRoot.py",
> line 40, in __init__
>     self.get(name)
>   File "/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py",
line 84,
> in get
>     val = val.getobj()
>   File "/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py",
line 52,
> in getobj
>     self.obj = klassobj()
>   File
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvNode.py",
> line 30, in __init__
>     self.xn = XendNode.instance()
>   File "/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py",
line
> 1176, in instance
>     inst = XendNode()
>   File "/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py",
line
> 163, in __init__
>     self._init_cpu_pools()
>   File "/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py",
line
> 377, in _init_cpu_pools
>     XendCPUPool.recreate_active_pools()
>   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendCPUPool.py",
> line 754, in recreate_active_pools
>     uuid = xstransact.Read(path, ''uuid'')
>   File  
>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
> line 307, in Read
>     return complete(path, lambda t: t.read(*args))
>   File  
>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
> line 361, in complete
>     t = xstransact(path)
>   File  
>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
> line 29, in __init__
>     self.transaction = xshandle().transaction_start()
>   File
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xsutil.py",
> line 18, in xshandle
>     xs_handle = xen.lowlevel.xs.xs()
> Error: (111, ''Connection refused'')
>
> Any ideas?
>
Is xenstore running? 

Are there files in /proc/xen ? 

-- Pasi
> Michal
>
>>
>>>> Thanks,
>>>> Michal
>>>>
>>>> On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
>>>>> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal Novotny
wrote:
>>>>>
>>>>>> Oh, one more thing I''ve discovered now. Since
the codebase for
>>>>>> qemu-xen-unstable is looking the same like for  
>>>>>> qemu-xen-3.4-testing and
>>>>>> the patch is applicable without any modifications it
could be working
>>>>>> for xen-4.1 unstable as well, unfortunately I was not
able to
>>>>>> boot PVOPS
>>>>>> kernel since it always ends up in kernel panic, maybe
the missing
>>>>>> drivers or something like that.
>>>>>>
>>>>>>
>>>>> What kernel version? Did you use xen/stable-2.6.32.x branch
from
>>>>> xen.git?
>>>>>
>>>>> See my example .config files from:
>>>>> http://wiki.xensource.com/xenwiki/XenParavirtOps in the  
>>>>> "troubleshooting" section.
>>>>>
>>>>> Works on F12/F13 dom0''s.
>>>>>
>>>>> For el5 dom0 you might need these:
>>>>>
http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>>>>>
>>>>> aka
>>>>> CONFIG_SYSFS_DEPRECATED=y
>>>>> CONFIG_SYSFS_DEPRECATED_V2=y
>>>>>
>>>>> Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y in
the .config
>>>>> because of the recently added pv-on-hvm drivers
(you''ll get build
>>>>> failure without that option),
>>>>> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or  
>>>>> XEN_NETDEV_FRONTEND or XEN_FBDEV_FRONTEND needs to be =y.
>>>>>
>>>>> -- Pasi
>>>>>
>>>>>
>>>>>
>>>>>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>>>>>
>>>>>>> Oh, just one more thing that should be mentioned:
>>>>>>>
>>>>>>> When you want to mount an image that is set as
read-only in
>>>>>>> the domain
>>>>>>> configuration file but you omit to set mode to
read-only it results
>>>>>>> into I/O errors when processing the requests.
Remounting as
>>>>>>> read-only
>>>>>>> or unmounting and remounting using the `mount
/dev/*
>>>>>>> /path/to/mount -o
>>>>>>> ro` shall do the mounting the correct way, i.e.
with no I/O
>>>>>>> errors, so
>>>>>>> make sure you mount those disks as read-only
otherwise you can be
>>>>>>> getting errors like:
>>>>>>>
>>>>>>> end_request: I/O error, dev hdb, sector 52
>>>>>>>
>>>>>>> Buffer I/O error on device hdb1, logical block 1
>>>>>>>
>>>>>>> lost page write due to I/O error on hdb1
>>>>>>>
>>>>>>>
>>>>>>> and for IDE devices you''ll be getting
several additional DeviceFault
>>>>>>> errors since mounting the device read-write
(default setting) writes
>>>>>>> some data onto a disk at the mount-time.
>>>>>>>
>>>>>>> Michal
>>>>>>>
>>>>>>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>>>>>>
>>>>>>>> [Well, I did send an e-mail to the list using
git but it''s not here
>>>>>>>> so I''m forwarding the e-mail to the
list for sure:]
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>> this is the patch for qemu-xen-3.4-testing to
fix the read-only
>>>>>>>> image file handling since the image file was
always treated as
>>>>>>>> read-write which means that all the HVM guests
were able to
>>>>>>>> write to all the disk images available in
domain configuration
>>>>>>>> file no matter what the mode of the image was
defined. This
>>>>>>>> patch fixes this functionality to honor the
O_RDONLY in the
>>>>>>>> BDRV_O_ACCESS flag in block.c and also fixes
the IDE and SCSI
>>>>>>>> interfaces that uses it.
>>>>>>>>
>>>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>>>> upstream xen with xen-3.4-testing qemu
implementation.
>>>>>>>>
>>>>>>>> For SCSI devices the DATA PROTECT request sense
has been added
>>>>>>>> as found at:  
>>>>>>>>
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>>>>>
>>>>>>>> file no matter what the mode of the image was
defined. This
>>>>>>>> patch fixes this functionality to honor the
O_RDONLY in the
>>>>>>>> BDRV_O_ACCESS flag in block.c and also fixes
the IDE and SCSI
>>>>>>>> interfaces that uses it.
>>>>>>>>
>>>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>>>> Michal
>>>>>>>>
>>>>>>>> Signed-off-by: Michal
Novotny<minovotn@redhat.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Xen-devel mailing list
>>>>>>>> Xen-devel@lists.xensource.com
>>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>>
>>>>>>>
>>>>>> -- 
>>>>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>>>>> Virtualization Team (xen userspace), Red Hat
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-devel
>>>>>>
>>>>
>>>> -- 
>>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>>> Virtualization Team (xen userspace), Red Hat
>>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>
>>
>
>
> -- 
> Michal Novotny<minovotn@redhat.com>, RHCE
> Virtualization Team (xen userspace), Red Hat
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 03:19 PM, Pasi Kärkkäinen wrote:
> On Mon, Jun 07, 2010 at 03:14:40PM +0200, Michal Novotny wrote:
>    
>> On 06/07/2010 03:10 PM, Michal Novotny wrote:
>>      
>>> On 06/07/2010 01:45 PM, Pasi Kärkkäinen wrote:
>>>        
>>>> On Mon, Jun 07, 2010 at 01:21:21PM +0200, Michal Novotny wrote:
>>>>          
>>>>> Well, I''m still having some tools issues, mainly:
>>>>>
>>>>> Error: (111, ''Connection refused'')
>>>>>
>>>>> Any guess what may be going wrong? Booted grub entry:
>>>>>
>>>>> title Red Hat Enterprise Linux Server (2.6.31.13-xen HV,
nolog)
>>>>>           root (hd1,6)
>>>>>           kernel /xen-4.1-unstable.gz
>>>>>           module /vmlinuz-2.6.31.13 ro root=LABEL=/rhel2
rhgb quiet
>>>>> selinux=0
>>>>>           module /initrd-2.6.31.13.img
>>>>>
>>>>> Mount is having `xenfs on /proc/xen type xenfs (rw)`. Any
guess
>>>>> what may
>>>>> be going wrong?
>>>>>
>>>>>            
>>>> Do you have xen-evtchn driver loaded?
>>>>
>>>>
>>>> -- Pasi
>>>>
>>>>          
>>> Well, no, and doesn''t seem to be installed/probed:
>>>
>>> # modprobe xen-evtchn
>>> # lsmod | grep xen-evtchn
>>> #
>>>
>>> So there''s the problem :(
>>>
>>> Michal
>>>        
>> Oh, I''m taking this back since I found out the module is not
xen-evtchn
>> but xen_evtchn. So yeah, I''m having it loaded in the memory
now.
>> However, when I do `service xend restart` the same error is here:
>>
>> [2010-06-07 17:14:09 5635] INFO (SrvDaemon:227) Xend stopped due to
>> signal 15.
>> [2010-06-07 17:14:09 6295] INFO (SrvDaemon:332) Xend Daemon started
>> [2010-06-07 17:14:09 6295] INFO (SrvDaemon:336) Xend changeset: Thu May
>> 20 17:22:15 2010 +0100 21442:a7fcf2e35d32.
>> [2010-06-07 17:14:09 6295] DEBUG (tcp:96) Listening on :8002
>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating
missing
>> unmanaged network eth0
>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating
missing
>> unmanaged network eth2
>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating
missing
>> unmanaged network br0
>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating
missing
>> unmanaged network xenbr0
>> [2010-06-07 17:14:10 6295] DEBUG (XendCPUPool:747)
recreate_active_pools
>> [2010-06-07 17:14:10 6295] ERROR (SrvDaemon:349) Exception starting
xend
>> ((111, ''Connection refused''))
>> Traceback (most recent call last):
>>    File
>>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDaemon.py",
line
>> 341, in run
>>      servers = SrvServer.create()
>>    File
>>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvServer.py",
line
>> 258, in create
>>      root.putChild(''xend'', SrvRoot())
>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvRoot.py",
>> line 40, in __init__
>>      self.get(name)
>>    File
"/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line 84,
>> in get
>>      val = val.getobj()
>>    File
"/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line 52,
>> in getobj
>>      self.obj = klassobj()
>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvNode.py",
>> line 30, in __init__
>>      self.xn = XendNode.instance()
>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py", line
>> 1176, in instance
>>      inst = XendNode()
>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py", line
>> 163, in __init__
>>      self._init_cpu_pools()
>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py", line
>> 377, in _init_cpu_pools
>>      XendCPUPool.recreate_active_pools()
>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendCPUPool.py",
>> line 754, in recreate_active_pools
>>      uuid = xstransact.Read(path, ''uuid'')
>>    File
>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
>> line 307, in Read
>>      return complete(path, lambda t: t.read(*args))
>>    File
>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
>> line 361, in complete
>>      t = xstransact(path)
>>    File
>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
>> line 29, in __init__
>>      self.transaction = xshandle().transaction_start()
>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xsutil.py",
>> line 18, in xshandle
>>      xs_handle = xen.lowlevel.xs.xs()
>> Error: (111, ''Connection refused'')
>>
>> Any ideas?
>>
>>      
> Is xenstore running?
>
> Are there files in /proc/xen ?
>
>    
Yes to both questions. Everything seems to be OK. Also, there''s option 
to turn on the debugging of xenstore, right? Do you think it could help? 
I''m going to try it now.

Michal
> -- Pasi
>
>    
>> Michal
>>
>>      
>>>        
>>>>> Thanks,
>>>>> Michal
>>>>>
>>>>> On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
>>>>>            
>>>>>> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal
Novotny wrote:
>>>>>>
>>>>>>              
>>>>>>> Oh, one more thing I''ve discovered now.
Since the codebase for
>>>>>>> qemu-xen-unstable is looking the same like for
>>>>>>> qemu-xen-3.4-testing and
>>>>>>> the patch is applicable without any modifications
it could be working
>>>>>>> for xen-4.1 unstable as well, unfortunately I was
not able to
>>>>>>> boot PVOPS
>>>>>>> kernel since it always ends up in kernel panic,
maybe the missing
>>>>>>> drivers or something like that.
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> What kernel version? Did you use xen/stable-2.6.32.x
branch from
>>>>>> xen.git?
>>>>>>
>>>>>> See my example .config files from:
>>>>>> http://wiki.xensource.com/xenwiki/XenParavirtOps in the
>>>>>> "troubleshooting" section.
>>>>>>
>>>>>> Works on F12/F13 dom0''s.
>>>>>>
>>>>>> For el5 dom0 you might need these:
>>>>>>
http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>>>>>>
>>>>>> aka
>>>>>> CONFIG_SYSFS_DEPRECATED=y
>>>>>> CONFIG_SYSFS_DEPRECATED_V2=y
>>>>>>
>>>>>> Also atm I think you need CONFIG_XEN_XENBUS_FRONTEND=y
in the .config
>>>>>> because of the recently added pv-on-hvm drivers
(you''ll get build
>>>>>> failure without that option),
>>>>>> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND or
>>>>>> XEN_NETDEV_FRONTEND or XEN_FBDEV_FRONTEND needs to be
=y.
>>>>>>
>>>>>> -- Pasi
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>>>>>>
>>>>>>>                
>>>>>>>> Oh, just one more thing that should be
mentioned:
>>>>>>>>
>>>>>>>> When you want to mount an image that is set as
read-only in
>>>>>>>> the domain
>>>>>>>> configuration file but you omit to set mode to
read-only it results
>>>>>>>> into I/O errors when processing the requests.
Remounting as
>>>>>>>> read-only
>>>>>>>> or unmounting and remounting using the `mount
/dev/*
>>>>>>>> /path/to/mount -o
>>>>>>>> ro` shall do the mounting the correct way, i.e.
with no I/O
>>>>>>>> errors, so
>>>>>>>> make sure you mount those disks as read-only
otherwise you can be
>>>>>>>> getting errors like:
>>>>>>>>
>>>>>>>> end_request: I/O error, dev hdb, sector 52
>>>>>>>>
>>>>>>>> Buffer I/O error on device hdb1, logical block
1
>>>>>>>>
>>>>>>>> lost page write due to I/O error on hdb1
>>>>>>>>
>>>>>>>>
>>>>>>>> and for IDE devices you''ll be getting
several additional DeviceFault
>>>>>>>> errors since mounting the device read-write
(default setting) writes
>>>>>>>> some data onto a disk at the mount-time.
>>>>>>>>
>>>>>>>> Michal
>>>>>>>>
>>>>>>>> On 06/03/2010 04:04 PM, Michal Novotny wrote:
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> [Well, I did send an e-mail to the list
using git but it''s not here
>>>>>>>>> so I''m forwarding the e-mail to
the list for sure:]
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> this is the patch for qemu-xen-3.4-testing
to fix the read-only
>>>>>>>>> image file handling since the image file
was always treated as
>>>>>>>>> read-write which means that all the HVM
guests were able to
>>>>>>>>> write to all the disk images available in
domain configuration
>>>>>>>>> file no matter what the mode of the image
was defined. This
>>>>>>>>> patch fixes this functionality to honor the
O_RDONLY in the
>>>>>>>>> BDRV_O_ACCESS flag in block.c and also
fixes the IDE and SCSI
>>>>>>>>> interfaces that uses it.
>>>>>>>>>
>>>>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>>>>> upstream xen with xen-3.4-testing qemu
implementation.
>>>>>>>>>
>>>>>>>>> For SCSI devices the DATA PROTECT request
sense has been added
>>>>>>>>> as found at:
>>>>>>>>>
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>>>>>>
>>>>>>>>> file no matter what the mode of the image
was defined. This
>>>>>>>>> patch fixes this functionality to honor the
O_RDONLY in the
>>>>>>>>> BDRV_O_ACCESS flag in block.c and also
fixes the IDE and SCSI
>>>>>>>>> interfaces that uses it.
>>>>>>>>>
>>>>>>>>> It''s been tested on RHEL-5 with
xen-3.4-testing version of
>>>>>>>>> Michal
>>>>>>>>>
>>>>>>>>> Signed-off-by: Michal
Novotny<minovotn@redhat.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
_______________________________________________
>>>>>>>>> Xen-devel mailing list
>>>>>>>>> Xen-devel@lists.xensource.com
>>>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>>                  
>>>>>>> -- 
>>>>>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>>>>>> Virtualization Team (xen userspace), Red Hat
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xen-devel mailing list
>>>>>>> Xen-devel@lists.xensource.com
>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>
>>>>>>>                
>>>>> -- 
>>>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>>>> Virtualization Team (xen userspace), Red Hat
>>>>>
>>>>>            
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>>>>          
>>>
>>>        
>>
>> -- 
>> Michal Novotny<minovotn@redhat.com>, RHCE
>> Virtualization Team (xen userspace), Red Hat
>>
>>      
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, 7 Jun 2010, Michal Novotny wrote:
> # modprobe xen-evtchn
> # lsmod | grep xen-evtchn
It is xen_evtchn in lsmod for me.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 03:21 PM, Michal Novotny wrote:
> On 06/07/2010 03:19 PM, Pasi Kärkkäinen wrote:
>> On Mon, Jun 07, 2010 at 03:14:40PM +0200, Michal Novotny wrote:
>>> On 06/07/2010 03:10 PM, Michal Novotny wrote:
>>>> On 06/07/2010 01:45 PM, Pasi Kärkkäinen wrote:
>>>>> On Mon, Jun 07, 2010 at 01:21:21PM +0200, Michal Novotny
wrote:
>>>>>> Well, I''m still having some tools issues,
mainly:
>>>>>>
>>>>>> Error: (111, ''Connection refused'')
>>>>>>
>>>>>> Any guess what may be going wrong? Booted grub entry:
>>>>>>
>>>>>> title Red Hat Enterprise Linux Server (2.6.31.13-xen
HV, nolog)
>>>>>>           root (hd1,6)
>>>>>>           kernel /xen-4.1-unstable.gz
>>>>>>           module /vmlinuz-2.6.31.13 ro
root=LABEL=/rhel2 rhgb quiet
>>>>>> selinux=0
>>>>>>           module /initrd-2.6.31.13.img
>>>>>>
>>>>>> Mount is having `xenfs on /proc/xen type xenfs (rw)`.
Any guess
>>>>>> what may
>>>>>> be going wrong?
>>>>>>
>>>>> Do you have xen-evtchn driver loaded?
>>>>>
>>>>>
>>>>> -- Pasi
>>>>>
>>>> Well, no, and doesn''t seem to be installed/probed:
>>>>
>>>> # modprobe xen-evtchn
>>>> # lsmod | grep xen-evtchn
>>>> #
>>>>
>>>> So there''s the problem :(
>>>>
>>>> Michal
>>> Oh, I''m taking this back since I found out the module is
not xen-evtchn
>>> but xen_evtchn. So yeah, I''m having it loaded in the
memory now.
>>> However, when I do `service xend restart` the same error is here:
>>>
>>> [2010-06-07 17:14:09 5635] INFO (SrvDaemon:227) Xend stopped due to
>>> signal 15.
>>> [2010-06-07 17:14:09 6295] INFO (SrvDaemon:332) Xend Daemon started
>>> [2010-06-07 17:14:09 6295] INFO (SrvDaemon:336) Xend changeset: Thu
May
>>> 20 17:22:15 2010 +0100 21442:a7fcf2e35d32.
>>> [2010-06-07 17:14:09 6295] DEBUG (tcp:96) Listening on :8002
>>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating 
>>> missing
>>> unmanaged network eth0
>>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating 
>>> missing
>>> unmanaged network eth2
>>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating 
>>> missing
>>> unmanaged network br0
>>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not recreating 
>>> missing
>>> unmanaged network xenbr0
>>> [2010-06-07 17:14:10 6295] DEBUG (XendCPUPool:747) 
>>> recreate_active_pools
>>> [2010-06-07 17:14:10 6295] ERROR (SrvDaemon:349) Exception starting
>>> xend
>>> ((111, ''Connection refused''))
>>> Traceback (most recent call last):
>>>    File
>>>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDaemon.py",
line
>>> 341, in run
>>>      servers = SrvServer.create()
>>>    File
>>>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvServer.py",
line
>>> 258, in create
>>>      root.putChild(''xend'', SrvRoot())
>>>    File 
>>>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvRoot.py",
>>> line 40, in __init__
>>>      self.get(name)
>>>    File
"/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line
>>> 84,
>>> in get
>>>      val = val.getobj()
>>>    File
"/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py", line
>>> 52,
>>> in getobj
>>>      self.obj = klassobj()
>>>    File 
>>>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvNode.py",
>>> line 30, in __init__
>>>      self.xn = XendNode.instance()
>>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py", line
>>> 1176, in instance
>>>      inst = XendNode()
>>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py", line
>>> 163, in __init__
>>>      self._init_cpu_pools()
>>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py", line
>>> 377, in _init_cpu_pools
>>>      XendCPUPool.recreate_active_pools()
>>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendCPUPool.py",
>>> line 754, in recreate_active_pools
>>>      uuid = xstransact.Read(path, ''uuid'')
>>>    File
>>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
>>> line 307, in Read
>>>      return complete(path, lambda t: t.read(*args))
>>>    File
>>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
>>> line 361, in complete
>>>      t = xstransact(path)
>>>    File
>>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
>>> line 29, in __init__
>>>      self.transaction = xshandle().transaction_start()
>>>    File 
>>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xsutil.py",
>>> line 18, in xshandle
>>>      xs_handle = xen.lowlevel.xs.xs()
>>> Error: (111, ''Connection refused'')
>>>
>>> Any ideas?
>>>
>> Is xenstore running?
>>
>> Are there files in /proc/xen ?
>>
>
> Yes to both questions. Everything seems to be OK. Also, there''s
option
> to turn on the debugging of xenstore, right? Do you think it could 
> help? I''m going to try it now.
>
> Michal
Well, I don''t know what was wrong but when I turned on the debugging it
was finally working fine to run xen daemon and also when I killed 
xenstore and turned off the debugging. `xm list` was working fine but I 
don''t know why so it''s a kind of magic to me. Nevertheless, it
appears
to be working fine by now.

Thanks for your help!
Michal
>> -- Pasi
>>
>>> Michal
>>>
>>>>>> Thanks,
>>>>>> Michal
>>>>>>
>>>>>> On 06/04/2010 12:42 PM, Pasi Kärkkäinen wrote:
>>>>>>> On Fri, Jun 04, 2010 at 11:37:51AM +0200, Michal
Novotny wrote:
>>>>>>>
>>>>>>>> Oh, one more thing I''ve discovered
now. Since the codebase for
>>>>>>>> qemu-xen-unstable is looking the same like for
>>>>>>>> qemu-xen-3.4-testing and
>>>>>>>> the patch is applicable without any
modifications it could be
>>>>>>>> working
>>>>>>>> for xen-4.1 unstable as well, unfortunately I
was not able to
>>>>>>>> boot PVOPS
>>>>>>>> kernel since it always ends up in kernel panic,
maybe the missing
>>>>>>>> drivers or something like that.
>>>>>>>>
>>>>>>>>
>>>>>>> What kernel version? Did you use
xen/stable-2.6.32.x branch from
>>>>>>> xen.git?
>>>>>>>
>>>>>>> See my example .config files from:
>>>>>>> http://wiki.xensource.com/xenwiki/XenParavirtOps in
the
>>>>>>> "troubleshooting" section.
>>>>>>>
>>>>>>> Works on F12/F13 dom0''s.
>>>>>>>
>>>>>>> For el5 dom0 you might need these:
>>>>>>>
http://wiki.xensource.com/xenwiki/2.6.18-to-2.6.31-and-higher
>>>>>>>
>>>>>>> aka
>>>>>>> CONFIG_SYSFS_DEPRECATED=y
>>>>>>> CONFIG_SYSFS_DEPRECATED_V2=y
>>>>>>>
>>>>>>> Also atm I think you need
CONFIG_XEN_XENBUS_FRONTEND=y in the
>>>>>>> .config
>>>>>>> because of the recently added pv-on-hvm drivers
(you''ll get build
>>>>>>> failure without that option),
>>>>>>> so you need XEN_PCIDEV_FRONTEND XEN_BLKDEV_FRONTEND
or
>>>>>>> XEN_NETDEV_FRONTEND or XEN_FBDEV_FRONTEND needs to
be =y.
>>>>>>>
>>>>>>> -- Pasi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 06/03/2010 04:12 PM, Michal Novotny wrote:
>>>>>>>>
>>>>>>>>> Oh, just one more thing that should be
mentioned:
>>>>>>>>>
>>>>>>>>> When you want to mount an image that is set
as read-only in
>>>>>>>>> the domain
>>>>>>>>> configuration file but you omit to set mode
to read-only it
>>>>>>>>> results
>>>>>>>>> into I/O errors when processing the
requests. Remounting as
>>>>>>>>> read-only
>>>>>>>>> or unmounting and remounting using the
`mount /dev/*
>>>>>>>>> /path/to/mount -o
>>>>>>>>> ro` shall do the mounting the correct way,
i.e. with no I/O
>>>>>>>>> errors, so
>>>>>>>>> make sure you mount those disks as
read-only otherwise you can be
>>>>>>>>> getting errors like:
>>>>>>>>>
>>>>>>>>> end_request: I/O error, dev hdb, sector 52
>>>>>>>>>
>>>>>>>>> Buffer I/O error on device hdb1, logical
block 1
>>>>>>>>>
>>>>>>>>> lost page write due to I/O error on hdb1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> and for IDE devices you''ll be
getting several additional
>>>>>>>>> DeviceFault
>>>>>>>>> errors since mounting the device read-write
(default setting)
>>>>>>>>> writes
>>>>>>>>> some data onto a disk at the mount-time.
>>>>>>>>>
>>>>>>>>> Michal
>>>>>>>>>
>>>>>>>>> On 06/03/2010 04:04 PM, Michal Novotny
wrote:
>>>>>>>>>
>>>>>>>>>> [Well, I did send an e-mail to the list
using git but it''s
>>>>>>>>>> not here
>>>>>>>>>> so I''m forwarding the e-mail
to the list for sure:]
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> this is the patch for
qemu-xen-3.4-testing to fix the read-only
>>>>>>>>>> image file handling since the image
file was always treated as
>>>>>>>>>> read-write which means that all the HVM
guests were able to
>>>>>>>>>> write to all the disk images available
in domain configuration
>>>>>>>>>> file no matter what the mode of the
image was defined. This
>>>>>>>>>> patch fixes this functionality to honor
the O_RDONLY in the
>>>>>>>>>> BDRV_O_ACCESS flag in block.c and also
fixes the IDE and SCSI
>>>>>>>>>> interfaces that uses it.
>>>>>>>>>>
>>>>>>>>>> It''s been tested on RHEL-5
with xen-3.4-testing version of
>>>>>>>>>> upstream xen with xen-3.4-testing qemu
implementation.
>>>>>>>>>>
>>>>>>>>>> For SCSI devices the DATA PROTECT
request sense has been added
>>>>>>>>>> as found at:
>>>>>>>>>>
http://en.wikipedia.org/wiki/SCSI_Request_Sense_Command
>>>>>>>>>>
>>>>>>>>>> file no matter what the mode of the
image was defined. This
>>>>>>>>>> patch fixes this functionality to honor
the O_RDONLY in the
>>>>>>>>>> BDRV_O_ACCESS flag in block.c and also
fixes the IDE and SCSI
>>>>>>>>>> interfaces that uses it.
>>>>>>>>>>
>>>>>>>>>> It''s been tested on RHEL-5
with xen-3.4-testing version of
>>>>>>>>>> Michal
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Michal
Novotny<minovotn@redhat.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
_______________________________________________
>>>>>>>>>> Xen-devel mailing list
>>>>>>>>>> Xen-devel@lists.xensource.com
>>>>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>>>>>>> Virtualization Team (xen userspace), Red Hat
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Xen-devel mailing list
>>>>>>>> Xen-devel@lists.xensource.com
>>>>>>>> http://lists.xensource.com/xen-devel
>>>>>>>>
>>>>>> -- 
>>>>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>>>>> Virtualization Team (xen userspace), Red Hat
>>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/xen-devel
>>>>
>>>
>>> -- 
>>> Michal Novotny<minovotn@redhat.com>, RHCE
>>> Virtualization Team (xen userspace), Red Hat
>>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Well,
it doesn''t seem to be that easy because I can''t boot any of
the guests.
No matter whether HVM or PV.

For PV it''s connected with the hotplugging:

# xm create rhel5-32pv
Using config file "./rhel5-32pv".
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

fragment from xend.log:

[2010-06-07 17:30:30 6690] DEBUG (XendDomainInfo:103) 
XendDomainInfo.create([''vm'', [''name'',
''rhel5-32pv''], [''memory'', 512],
[''maxmem'', 512], [''on_poweroff'',
''destroy''], [''on_reboot'',
''restart''],
[''on_crash'', ''restart''],
[''on_xend_start'', ''ignore''],
[''on_xend_stop'',
''ignore''], [''vcpu_avail'', 3],
[''vcpus'', 4], [''uuid'',
''731497a6-2c62-8cfb-0afb-4e1ff7bde24d''],
[''oos'', 1], [''bootloader'',
''/usr/bin/pygrub''], [''bootloader_args'',
''-q''], [''image'', [''linux'',
[''videoram'', 4], [''tsc_mode'', 0],
[''nomigrate'', 0]]], [''s3_integrity'',
1], [''device'', [''tap'',
[''uname'',
''tap:aio:/var/lib/xen/images/colossus/rhel5-32pv.img''],
[''dev'', ''xvda''],
[''mode'', ''w'']]],
[''device'', [''vif'',
[''bridge'', ''xenbr0''],
[''mac'',
''00:16:3e:30:d0:e2'']]]])
[2010-06-07 17:30:30 6690] DEBUG (XendDomainInfo:2510) 
XendDomainInfo.constructDomain
[2010-06-07 17:30:30 6690] DEBUG (balloon:187) Balloon: 638692 KiB free; 
need 16384; done.
[2010-06-07 17:30:30 6690] DEBUG (XendDomain:464) Adding Domain: 5
[2010-06-07 17:30:30 6690] DEBUG (XendDomainInfo:2848) 
XendDomainInfo.initDomain: 5 256
[2010-06-07 17:30:30 6852] DEBUG (XendBootloader:113) Launching 
bootloader as [''/usr/bin/pygrub'', 
''--output=/var/run/xend/boot/xenbl.23510'',
''-q'',
''/var/lib/xen/images/colossus/rhel5-32pv.img''].
[2010-06-07 17:30:31 6690] DEBUG (XendDomainInfo:2875) 
_initDomain:shadow_memory=0x0, memory_static_max=0x20000000, 
memory_static_min=0x0.
[2010-06-07 17:30:31 6690] INFO (image:182) buildDomain os=linux dom=5 
vcpus=4
[2010-06-07 17:30:31 6690] DEBUG (image:721) domid          = 5
[2010-06-07 17:30:31 6690] DEBUG (image:722) memsize        = 512
[2010-06-07 17:30:31 6690] DEBUG (image:723) image          = 
/var/run/xend/boot/boot_kernel.K5aHnG
[2010-06-07 17:30:31 6690] DEBUG (image:724) store_evtchn   = 1
[2010-06-07 17:30:31 6690] DEBUG (image:725) console_evtchn = 2
[2010-06-07 17:30:31 6690] DEBUG (image:726) cmdline        = ro 
root=/dev/VolGroup00/LogVol00 rhgb quiet
[2010-06-07 17:30:31 6690] DEBUG (image:727) ramdisk        = 
/var/run/xend/boot/boot_ramdisk.q7eD9J
[2010-06-07 17:30:31 6690] DEBUG (image:728) vcpus          = 4
[2010-06-07 17:30:31 6690] DEBUG (image:729) features       [2010-06-07 17:30:31
6690] DEBUG (image:730) flags          = 0
[2010-06-07 17:30:31 6690] DEBUG (image:731) superpages     = 0
[2010-06-07 17:30:31 6690] INFO (XendDomainInfo:2369) createDevice: tap 
: {''bootable'': 1, ''uname'': 
''tap:aio:/var/lib/xen/images/colossus/rhel5-32pv.img'',
''mode'': ''w'',
''dev'': ''xvda'', ''uuid'':
''ec14b93e-99df-8d7e-eac0-2aaa9332d6f6''}
[2010-06-07 17:30:31 6690] DEBUG (DevController:95) DevController: 
writing {''virtual-device'': ''51712'',
''device-type'': ''disk'',
''protocol'':
''x86_32-abi'', ''backend-id'':
''0'', ''state'': ''1'',
''backend'':
''/local/domain/0/backend/tap/5/51712''} to
/local/domain/5/device/vbd/51712.
[2010-06-07 17:30:31 6690] DEBUG (DevController:97) DevController: 
writing {''domain'': ''rhel5-32pv'',
''frontend'':
''/local/domain/5/device/vbd/51712'', ''uuid'': 
''ec14b93e-99df-8d7e-eac0-2aaa9332d6f6'',
''bootable'': ''1'', ''dev'':
''xvda'',
''state'': ''1'', ''params'': 
''aio:/var/lib/xen/images/colossus/rhel5-32pv.img'',
''mode'': ''w'',
''online'': ''1'',
''frontend-id'': ''5'',
''type'': ''tap''} to
/local/domain/0/backend/tap/5/51712.
[2010-06-07 17:30:31 6690] INFO (XendDomainInfo:2369) createDevice: vif 
: {''bridge'': ''xenbr0'',
''mac'': ''00:16:3e:30:d0:e2'',
''uuid'':
''ca69ce95-45d3-8b63-9e42-1ee256014264''}
[2010-06-07 17:30:31 6690] DEBUG (DevController:95) DevController: 
writing {''mac'': ''00:16:3e:30:d0:e2'',
''handle'': ''0'', ''protocol'':
''x86_32-abi'', ''backend-id'':
''0'', ''state'': ''1'',
''backend'':
''/local/domain/0/backend/vif/5/0''} to
/local/domain/5/device/vif/0.
[2010-06-07 17:30:31 6690] DEBUG (DevController:97) DevController: 
writing {''bridge'': ''xenbr0'',
''domain'': ''rhel5-32pv'',
''handle'': ''0'',
''uuid'':
''ca69ce95-45d3-8b63-9e42-1ee256014264'',
''script'':
''/etc/xen/scripts/vif-bridge'', ''mac'':
''00:16:3e:30:d0:e2'',
''frontend-id'': ''5'',
''state'': ''1'', ''online'':
''1'', ''frontend'':
''/local/domain/5/device/vif/0''} to
/local/domain/0/backend/vif/5/0.
[2010-06-07 17:30:31 6690] DEBUG (XendDomainInfo:3430) Storing VM 
details: {''on_xend_stop'': ''ignore'',
''pool_name'': ''Pool-0'',
''shadow_memory'': ''0'',
''uuid'':
''731497a6-2c62-8cfb-0afb-4e1ff7bde24d'',
''on_reboot'': ''restart'',
''start_time'': ''1275924631.91'',
''on_poweroff'':
''destroy'', ''bootloader_args'':
''-q'', ''on_xend_start'':
''ignore'',
''on_crash'': ''restart'',
''xend/restart_count'': ''0'',
''vcpus'': ''4'',
''vcpu_avail'': ''3'',
''bootloader'': ''/usr/bin/pygrub'',
''image'': "(linux
(kernel ) (superpages 0) (tsc_mode 0) (videoram 4) (pci ()) (nomigrate 
0) (notes (FEATURES 
''writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel'')
(VIRT_BASE 3221225472) (GUEST_VERSION 2.6) (PADDR_OFFSET 3221225472) 
(GUEST_OS linux) (HYPERCALL_PAGE 3225423872) (LOADER generic) (PAE_MODE 
yes) (ENTRY 3225419776) (XEN_VERSION xen-3.0)))", ''name'':
''rhel5-32pv''}
[2010-06-07 17:30:31 6690] DEBUG (XendDomainInfo:1806) Storing domain 
details: {''console/ring-ref'': ''1066161'',
''image/entry'': ''3225419776'',
''console/port'': ''2'',
''cpu/3/availability'': ''offline'',
''store/ring-ref'':
''1066162'', ''image/loader'':
''generic'', ''vm'':
''/vm/731497a6-2c62-8cfb-0afb-4e1ff7bde24d'', 
''control/platform-feature-multiprocessor-suspend'':
''1'', ''description'':
'''', ''cpu/2/availability'':
''offline'', ''cpu/1/availability'':
''online'',
''image/features/writable-descriptor-tables'':
''1'', ''image/virt-base'':
''3221225472'', ''memory/target'':
''524288'', ''image/guest-version'':
''2.6'',
''image/features/supervisor-mode-kernel'':
''1'', ''image/pae-mode'':
''yes'',
''image/guest-os'': ''linux'',
''console/limit'': ''1048576'',
''image/paddr-offset'': ''3221225472'',
''image/hypercall-page'':
''3225423872'', ''cpu/0/availability'':
''online'',
''image/features/pae-pgdir-above-4gb'': ''1'', 
''image/features/writable-page-tables'': ''1'',
''console/type'':
''xenconsoled'',
''image/features/auto-translated-physmap'':
''1'', ''name'':
''rhel5-32pv'', ''domid'':
''5'', ''image/xen-version'':
''xen-3.0'',
''store/port'': ''1''}
[2010-06-07 17:30:32 6690] DEBUG (DevController:95) DevController: 
writing {''protocol'': ''x86_32-abi'',
''state'': ''1'',
''backend-id'': ''0'',
''backend'':
''/local/domain/0/backend/console/5/0''} to
/local/domain/5/device/console/0.
[2010-06-07 17:30:32 6690] DEBUG (DevController:97) DevController: 
writing {''domain'': ''rhel5-32pv'',
''frontend'':
''/local/domain/5/device/console/0'', ''uuid'': 
''2621cc44-62ab-8520-102d-cb34c2cc8cb7'',
''frontend-id'': ''5'',
''state'':
''1'', ''location'': ''2'',
''online'': ''1'', ''protocol'':
''vt100''} to
/local/domain/0/backend/console/5/0.
[2010-06-07 17:30:32 6690] DEBUG (XendDomainInfo:1893) 
XendDomainInfo.handleShutdownWatch
[2010-06-07 17:30:32 6690] DEBUG (DevController:139) Waiting for devices 
vif2.
[2010-06-07 17:30:32 6690] DEBUG (DevController:139) Waiting for devices 
vif.
[2010-06-07 17:30:32 6690] DEBUG (DevController:144) Waiting for 0.
[2010-06-07 17:30:32 6690] DEBUG (DevController:628) 
hotplugStatusCallback /local/domain/0/backend/vif/5/0/hotplug-status.


[2010-06-07 17:32:12 6690] DEBUG (XendDomainInfo:3083) 
XendDomainInfo.destroy: domid=5
[2010-06-07 17:32:12 6690] DEBUG (XendDomainInfo:2413) Destroying device 
model
[2010-06-07 17:32:12 6690] DEBUG (XendDomainInfo:2420) Releasing devices
[2010-06-07 17:32:12 6690] DEBUG (XendDomainInfo:2426) Removing vif/0
[2010-06-07 17:32:12 6690] DEBUG (XendDomainInfo:1288) 
XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0
[2010-06-07 17:32:12 6690] DEBUG (XendDomainInfo:2426) Removing console/0
[2010-06-07 17:32:12 6690] DEBUG (XendDomainInfo:1288) 
XendDomainInfo.destroyDevice: deviceClass = console, device = console/0
[2010-06-07 17:32:12 6690] DEBUG (XendDomainInfo:2426) Removing tap/51712
[2010-06-07 17:32:12 6690] DEBUG (XendDomainInfo:1288) 
XendDomainInfo.destroyDevice: deviceClass = tap, device = tap/51712

For HVM guests it''s:

# xm create rhel5-32fv
Using config file "./rhel5-32fv".
Error: Not enough memory is available, and dom0 cannot be shrunk any further

and also the xend.log fragment relevant to the issue:

[2010-06-07 17:34:30 6690] DEBUG (XendDomainInfo:103) 
XendDomainInfo.create([''vm'', [''name'',
''rhel5-32fv''], [''memory'', 1024],
[''maxmem'', 1024], [''on_poweroff'',
''destroy''], [''on_reboot'',
''restart''],
[''on_crash'', ''restart''],
[''on_xend_start'', ''ignore''],
[''on_xend_stop'',
''ignore''], [''vcpus'', 1],
[''uuid'',
''a21e0a64-8fbe-48c2-f28e-9c1cfc7427c7''],
[''oos'', 1], [''image'',
[''hvm'',
[''kernel'', ''/usr/lib/xen/boot/hvmloader''],
[''videoram'', 4], [''parallel'',
''none''], [''serial'',
''pty''], [''acpi'', 1],
[''apic'', 1], [''boot'',
''c''],
[''cpuid'', []], [''cpuid_check'', []],
[''device_model'',
''/usr/lib64/xen/bin/qemu-dm''], [''fda'',
''''], [''fdb'', ''''],
[''guest_os_type'', ''default''],
[''hap'', 1], [''hpet'', 0],
[''isa'', 0],
[''keymap'', ''en-us''],
[''localtime'', 0], [''nographic'', 0],
[''oos'', 1],
[''pae'', 1], [''pci'', []],
[''pci_msitranslate'', 1], [''pci_power_mgmt'',
0],
[''rtc_timeoffset'', 0], [''sdl'', 0],
[''soundhw'', ''''],
[''stdvga'', 0],
[''timer_mode'', 1], [''usb'', 0],
[''usbdevice'', ''''],
[''vcpus'', 1], [''vnc'',
1], [''vncdisplay'', 5], [''vncunused'', 0],
[''viridian'', 0], [''vpt_align'',
1], [''xauthority'', ''/root/.Xauthority''],
[''xen_platform_pci'', 1],
[''memory_sharing'', 0], [''tsc_mode'', 0],
[''nomigrate'', 0]]],
[''s3_integrity'', 1], [''device'',
[''vbd'', [''uname'',
''file:/var/lib/xen/images/colossus/rhel5-32fv.img''],
[''dev'', ''hda''],
[''mode'', ''w'']]],
[''device'', [''vbd'',
[''uname'', ''file:/home2/test.img''],
[''dev'', ''sda''], [''mode'',
''w'']]], [''device'', [''vif'',
[''bridge'', ''eth0''],
[''mac'', ''00:16:3e:6b:d5:c0''],
[''type'', ''netfront'']]]])
[2010-06-07 17:34:30 6690] DEBUG (XendDomainInfo:2510) 
XendDomainInfo.constructDomain
[2010-06-07 17:34:30 6690] DEBUG (balloon:187) Balloon: 638692 KiB free; 
need 16384; done.
[2010-06-07 17:34:30 6690] DEBUG (XendDomain:464) Adding Domain: 6
[2010-06-07 17:34:30 6690] DEBUG (XendDomainInfo:2848) 
XendDomainInfo.initDomain: 6 256
[2010-06-07 17:34:30 6690] DEBUG (image:339) No VNC passwd configured 
for vfb access
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: boot, val: c
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: fda, val: None
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: fdb, val: None
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: soundhw, val: None
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: localtime, val: 0
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: serial, val:
[''pty'']
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: std-vga, val: 0
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: isa, val: 0
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: acpi, val: 1
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: usb, val: 0
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: usbdevice, val: None
[2010-06-07 17:34:31 6690] DEBUG (image:889) args: gfx_passthru, val: None
[2010-06-07 17:34:31 6690] INFO (image:822) Need to create platform 
device.[domid:6]
[2010-06-07 17:34:31 6690] DEBUG (XendDomainInfo:2875) 
_initDomain:shadow_memory=0x0, memory_static_max=0x40000000, 
memory_static_min=0x0.
[2010-06-07 17:34:31 6690] DEBUG (balloon:172) Balloon: tmem 
relinquished 0 KiB of 431872 KiB requested.
[2010-06-07 17:34:31 6690] DEBUG (balloon:193) Balloon: 634112 KiB free; 
0 to scrub; need 1065984; retries: 20.
[2010-06-07 17:34:31 6690] DEBUG (balloon:207) Balloon: setting dom0 
target to 7524 MiB.
[2010-06-07 17:34:31 6690] DEBUG (XendDomainInfo:1479) Setting memory 
target of domain Domain-0 (0) to 7524 MiB.
[2010-06-07 17:34:31 6690] DEBUG (balloon:193) Balloon: 634112 KiB free; 
0 to scrub; need 1065984; retries: 20.




[2010-06-07 17:34:54 6690] DEBUG (XendDomainInfo:1479) Setting memory 
target of domain Domain-0 (0) to 7945 MiB.
[2010-06-07 17:34:54 6690] DEBUG (balloon:187) Balloon: 634112 KiB free; 
need 431104; done.
[2010-06-07 17:34:54 6690] ERROR (XendDomainInfo:2934) 
XendDomainInfo.initDomain: exception occurred
Traceback (most recent call last):
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 2893, in _initDomain
     balloon.free(memory + shadow + vtd_mem, self)
   File "/usr/lib64/python2.4/site-packages/xen/xend/balloon.py", line
237, in free
     raise VmError(
VmError: Not enough memory is available, and dom0 cannot be shrunk any 
further
[2010-06-07 17:34:54 6690] ERROR (XendDomainInfo:485) VM start failed
Traceback (most recent call last):
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 471, in start
     XendTask.log_progress(31, 60, self._initDomain)
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendTask.py",
line
209, in log_progress
     retval = func(*args, **kwds)
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 2937, in _initDomain
     raise exn
VmError: Not enough memory is available, and dom0 cannot be shrunk any 
further
[2010-06-07 17:34:54 6690] DEBUG (XendDomainInfo:3083) 
XendDomainInfo.destroy: domid=6
[2010-06-07 17:34:54 6690] DEBUG (XendDomainInfo:2413) Destroying device 
model
[2010-06-07 17:34:54 6690] ERROR (XendDomainInfo:2416) Device model 
destroy failed X86_HVM_ImageHandler instance has no attribute 
''sentinel_lock''
Traceback (most recent call last):
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 2414, in _releaseDevices
     self.image.destroyDeviceModel()
   File "/usr/lib64/python2.4/site-packages/xen/xend/image.py", line 
621, in destroyDeviceModel
     self.sentinel_lock.acquire()
AttributeError: X86_HVM_ImageHandler instance has no attribute 
''sentinel_lock''
[2010-06-07 17:34:54 6690] DEBUG (XendDomainInfo:2420) Releasing devices
[2010-06-07 17:34:54 6690] ERROR (XendDomainInfo:108) Domain 
construction failed
Traceback (most recent call last):
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 106, in create
     vm.start()
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 471, in start
     XendTask.log_progress(31, 60, self._initDomain)
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendTask.py",
line
209, in log_progress
     retval = func(*args, **kwds)
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 2937, in _initDomain
     raise exn
VmError: Not enough memory is available, and dom0 cannot be shrunk any 
further

For PV guests there was a change of blktap to blktap2. Couldn''t this be
related? How could I check I''m using the blktap2 ? Also, my test
machine
is Intel Xeon X5460 @ 3.16 Ghz, quad-core with 8 GiB RAM running on 
RHEL-5 with upstream 4.1 xen.

Michal


-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 07/06/2010 14:36, "Michal Novotny" <minovotn@redhat.com>
wrote:
> For HVM guests it''s:
> 
> # xm create rhel5-32fv
> Using config file "./rhel5-32fv".
> Error: Not enough memory is available, and dom0 cannot be shrunk any
further
> 
> and also the xend.log fragment relevant to the issue:
Try no-tmem on Xen command line.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Jun 07, 2010 at 03:25:48PM +0200, Michal Novotny
wrote:
>>>>>>>
>>>>>> Do you have xen-evtchn driver loaded?
>>>>>>
>>>>>>
>>>>>> -- Pasi
>>>>>>
>>>>> Well, no, and doesn''t seem to be installed/probed:
>>>>>
>>>>> # modprobe xen-evtchn
>>>>> # lsmod | grep xen-evtchn
>>>>> #
>>>>>
>>>>> So there''s the problem :(
>>>>>
>>>>> Michal
>>>> Oh, I''m taking this back since I found out the module
is not xen-evtchn
>>>> but xen_evtchn. So yeah, I''m having it loaded in the
memory now.
>>>> However, when I do `service xend restart` the same error is
here:
>>>>
>>>> [2010-06-07 17:14:09 5635] INFO (SrvDaemon:227) Xend stopped
due to
>>>> signal 15.
>>>> [2010-06-07 17:14:09 6295] INFO (SrvDaemon:332) Xend Daemon
started
>>>> [2010-06-07 17:14:09 6295] INFO (SrvDaemon:336) Xend changeset:
Thu May
>>>> 20 17:22:15 2010 +0100 21442:a7fcf2e35d32.
>>>> [2010-06-07 17:14:09 6295] DEBUG (tcp:96) Listening on :8002
>>>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not
recreating
>>>> missing
>>>> unmanaged network eth0
>>>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not
recreating
>>>> missing
>>>> unmanaged network eth2
>>>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not
recreating
>>>> missing
>>>> unmanaged network br0
>>>> [2010-06-07 17:14:09 6295] INFO (XendNetwork:114) Not
recreating
>>>> missing
>>>> unmanaged network xenbr0
>>>> [2010-06-07 17:14:10 6295] DEBUG (XendCPUPool:747)  
>>>> recreate_active_pools
>>>> [2010-06-07 17:14:10 6295] ERROR (SrvDaemon:349) Exception
starting
>>>> xend
>>>> ((111, ''Connection refused''))
>>>> Traceback (most recent call last):
>>>>    File
>>>>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvDaemon.py",
line
>>>> 341, in run
>>>>      servers = SrvServer.create()
>>>>    File
>>>>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvServer.py",
line
>>>> 258, in create
>>>>      root.putChild(''xend'', SrvRoot())
>>>>    File  
>>>>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvRoot.py",
>>>> line 40, in __init__
>>>>      self.get(name)
>>>>    File
"/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py",
>>>> line 84,
>>>> in get
>>>>      val = val.getobj()
>>>>    File
"/usr/lib64/python2.4/site-packages/xen/web/SrvDir.py",
>>>> line 52,
>>>> in getobj
>>>>      self.obj = klassobj()
>>>>    File  
>>>>
"/usr/lib64/python2.4/site-packages/xen/xend/server/SrvNode.py",
>>>> line 30, in __init__
>>>>      self.xn = XendNode.instance()
>>>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py", line
>>>> 1176, in instance
>>>>      inst = XendNode()
>>>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py", line
>>>> 163, in __init__
>>>>      self._init_cpu_pools()
>>>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendNode.py", line
>>>> 377, in _init_cpu_pools
>>>>      XendCPUPool.recreate_active_pools()
>>>>    File
"/usr/lib64/python2.4/site-packages/xen/xend/XendCPUPool.py",
>>>> line 754, in recreate_active_pools
>>>>      uuid = xstransact.Read(path, ''uuid'')
>>>>    File
>>>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
>>>> line 307, in Read
>>>>      return complete(path, lambda t: t.read(*args))
>>>>    File
>>>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
>>>> line 361, in complete
>>>>      t = xstransact(path)
>>>>    File
>>>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xstransact.py",
>>>> line 29, in __init__
>>>>      self.transaction = xshandle().transaction_start()
>>>>    File  
>>>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xsutil.py",
>>>> line 18, in xshandle
>>>>      xs_handle = xen.lowlevel.xs.xs()
>>>> Error: (111, ''Connection refused'')
>>>>
>>>> Any ideas?
>>>>
>>> Is xenstore running?
>>>
>>> Are there files in /proc/xen ?
>>>
>>
>> Yes to both questions. Everything seems to be OK. Also,
there''s option
>> to turn on the debugging of xenstore, right? Do you think it could  
>> help? I''m going to try it now.
>>
>> Michal
>
> Well, I don''t know what was wrong but when I turned on the
debugging it
> was finally working fine to run xen daemon and also when I killed  
> xenstore and turned off the debugging. `xm list` was working fine but I  
> don''t know why so it''s a kind of magic to me.
Nevertheless, it appears
> to be working fine by now.
>
Ok, good to hear it works now :)

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Jun 07, 2010 at 03:36:44PM +0200, Michal Novotny
wrote:
> Well,
> it doesn''t seem to be that easy because I can''t boot any
of the guests.
> No matter whether HVM or PV.
>
> For PV it''s connected with the hotplugging:
>
> # xm create rhel5-32pv
> Using config file "./rhel5-32pv".
> Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
>
Do you have correct bridge= specified for the vif? Does the bridge exist? 

>
> For HVM guests it''s:
>
> # xm create rhel5-32fv
> Using config file "./rhel5-32fv".
> Error: Not enough memory is available, and dom0 cannot be shrunk any
further
>
Do you have dom0_mem=1024M for xen.gz in grub.conf ? 
You should limit/dedicate some memory for only dom0 and thus prevent the need
for ballooning.

> and also the xend.log fragment relevant to the issue:
>
>
> For PV guests there was a change of blktap to blktap2. Couldn''t
this be
> related? How could I check I''m using the blktap2 ? Also, my test
machine
> is Intel Xeon X5460 @ 3.16 Ghz, quad-core with 8 GiB RAM running on  
> RHEL-5 with upstream 4.1 xen.
>
Try first using just file:// if using image files, or phy: if using lvm volumes.

-- Pasi



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 03:46 PM, Keir Fraser wrote:
> On 07/06/2010 14:36, "Michal Novotny"<minovotn@redhat.com> 
wrote:
>
>    
>> For HVM guests it''s:
>>
>> # xm create rhel5-32fv
>> Using config file "./rhel5-32fv".
>> Error: Not enough memory is available, and dom0 cannot be shrunk any
further
>>
>> and also the xend.log fragment relevant to the issue:
>>      
> Try no-tmem on Xen command line.
>
>   -- Keir
>
>
>    
Keir, I did try:

title Red Hat Enterprise Linux Server (2.6.31.13-xen HV, nolog)
         root (hd1,6)
         kernel /xen-4.1-unstable.gz no-tmem
         module /vmlinuz-2.6.31.13 ro root=LABEL=/rhel2 rhgb quiet selinux=0
         module /initrd-2.6.31.13.img

and I was even unable to do `xm list` because of the issue with memory 
and also I found out that it''s not working when I reboot the system and
even when I put modprobe for xen-evtchn to xend init script so I need to 
`modprobe xen-evtchn` manually, then run xenstore daemon and then 
restart the xen daemon. Also, the /var/log/xen/xend.log file is 
completely empty and I am now unable to see what''s going on and I
cannot
run `xm list` at all so it was working a little until I restarted but 
I''m having many issues here.

Michal


-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 04:56 PM, Pasi Kärkkäinen wrote:
> On Mon, Jun 07, 2010 at 03:36:44PM +0200, Michal Novotny wrote:
>    
>> Well,
>> it doesn''t seem to be that easy because I can''t boot
any of the guests.
>> No matter whether HVM or PV.
>>
>> For PV it''s connected with the hotplugging:
>>
>> # xm create rhel5-32pv
>> Using config file "./rhel5-32pv".
>> Error: Device 0 (vif) could not be connected. Hotplug scripts not
working.
>>
>>      
> Do you have correct bridge= specified for the vif? Does the bridge exist?
>
>
>    
Yeah, everything is specified like it was and the bridge exists.
>> For HVM guests it''s:
>>
>> # xm create rhel5-32fv
>> Using config file "./rhel5-32fv".
>> Error: Not enough memory is available, and dom0 cannot be shrunk any
further
>>
>>      
> Do you have dom0_mem=1024M for xen.gz in grub.conf ?
> You should limit/dedicate some memory for only dom0 and thus prevent the
need for ballooning.
>
>
>    
  No, I''m not having dom0_mem here at all.
>> and also the xend.log fragment relevant to the issue:
>>
>>
>> For PV guests there was a change of blktap to blktap2.
Couldn''t this be
>> related? How could I check I''m using the blktap2 ? Also, my
test machine
>> is Intel Xeon X5460 @ 3.16 Ghz, quad-core with 8 GiB RAM running on
>> RHEL-5 with upstream 4.1 xen.
>>
>>      
> Try first using just file:// if using image files, or phy: if using lvm
volumes.
>
> -- Pasi
>
>
>    
Ok, I''m using image files. Unfortunately it''s not working
after reboot
so it''s pretty bad now.

Michal
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, 7 Jun 2010, Michal Novotny wrote:
> and I was even unable to do `xm list` because of the issue with memory and 
> also I found out that it''s not working when I reboot the system
and even when
> I put modprobe for xen-evtchn to xend init script so I need to `modprobe 
> xen-evtchn` manually, then run xenstore daemon and then restart the xen 
> daemon.
Are you running with selinux enabled? I have seen selinux cause startup 
issues with xen before. If you are it might be worth trying again in 
permissive mode and see if anything is different.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 05:17 PM, M A Young wrote:
> On Mon, 7 Jun 2010, Michal Novotny wrote:
>
>> and I was even unable to do `xm list` because of the issue with 
>> memory and also I found out that it''s not working when I
reboot the
>> system and even when I put modprobe for xen-evtchn to xend init 
>> script so I need to `modprobe xen-evtchn` manually, then run xenstore 
>> daemon and then restart the xen daemon.
>
> Are you running with selinux enabled? I have seen selinux cause 
> startup issues with xen before. If you are it might be worth trying 
> again in permissive mode and see if anything is different.
>
>     Michael Young
No, it''s selinux=0 on the kernel command line so disabled.

Michal
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Jun 07, 2010 at 03:36:44PM +0200, Michal Novotny
wrote:
> Well,
> it doesn''t seem to be that easy because I can''t boot any
of the guests.
> No matter whether HVM or PV.
>
> For PV it''s connected with the hotplugging:
>
> # xm create rhel5-32pv
> Using config file "./rhel5-32pv".
> Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
Make sure you have your tun module loaded (yeah, no need for it, but the
qemu-ifup might be touch it). Also you can take a look at
/var/log/xen/xen-hotplug to see what the error is.
> For HVM guests it''s: 
.. snip..
>
> # xm create rhel5-32fv
> Using config file "./rhel5-32fv".
> Error: Not enough memory is available, and dom0 cannot be shrunk any
further
Try xm mem-set 0 2048 before the start and see if that makes it work.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 06:12 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jun 07, 2010 at 03:36:44PM +0200, Michal Novotny wrote:
>    
>> Well,
>> it doesn''t seem to be that easy because I can''t boot
any of the guests.
>> No matter whether HVM or PV.
>>
>> For PV it''s connected with the hotplugging:
>>
>> # xm create rhel5-32pv
>> Using config file "./rhel5-32pv".
>> Error: Device 0 (vif) could not be connected. Hotplug scripts not
working.
>>      
> Make sure you have your tun module loaded (yeah, no need for it, but the
> qemu-ifup might be touch it). Also you can take a look at
> /var/log/xen/xen-hotplug to see what the error is.
>
>    
>> For HVM guests it''s:
>>      
> .. snip..
>    
>> # xm create rhel5-32fv
>> Using config file "./rhel5-32fv".
>> Error: Not enough memory is available, and dom0 cannot be shrunk any
further
>>      
> Try xm mem-set 0 2048 before the start and see if that makes it work.
>    
Well, now it changed to:

# xenstored
  FATAL: Failed to initialize dom0 state: Invalid argument

what does it mean and how to fix it?

Michal

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 07/06/2010 17:27, "Michal Novotny" <minovotn@redhat.com>
wrote:
>> Try xm mem-set 0 2048 before the start and see if that makes it work.
>>    
> Well, now it changed to:
> 
> # xenstored
>   FATAL: Failed to initialize dom0 state: Invalid argument
> 
> what does it mean and how to fix it?
Do files /proc/xen/xsd_kva and /proc/xen/xsd_port exist? If not you need to
configure and/or install the appropriate xenstore-related kernel module
(whatever that may be, in pv_ops land).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 06:34 PM, Keir Fraser wrote:
> On 07/06/2010 17:27, "Michal Novotny"<minovotn@redhat.com> 
wrote:
>
>    
>>> Try xm mem-set 0 2048 before the start and see if that makes it
work.
>>>
>>>        
>> Well, now it changed to:
>>
>> # xenstored
>>    FATAL: Failed to initialize dom0 state: Invalid argument
>>
>> what does it mean and how to fix it?
>>      
> Do files /proc/xen/xsd_kva and /proc/xen/xsd_port exist? If not you need to
> configure and/or install the appropriate xenstore-related kernel module
> (whatever that may be, in pv_ops land).
>
>   -- Keir
>    
Thanks but I checked it and they exist and it seems to be OK. Also, the 
strange thing is that even if I put modprobe to /etc/init.d/xend before 
start the module can''t get probed and lsmod is showing only xenfs
module
but no xen_evtchn loaded. I need to modprobe it manually, run xenstored 
manually and then after starting xen daemon the error of dom0 state happens.

Michal
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 07/06/2010 17:37, "Michal Novotny" <minovotn@redhat.com>
wrote:
>> Do files /proc/xen/xsd_kva and /proc/xen/xsd_port exist? If not you
need to
>> configure and/or install the appropriate xenstore-related kernel module
>> (whatever that may be, in pv_ops land).
>> 
>>   -- Keir
>>    
> 
> Thanks but I checked it and they exist and it seems to be OK. Also, the
> strange thing is that even if I put modprobe to /etc/init.d/xend before
> start the module can''t get probed and lsmod is showing only xenfs
module
> but no xen_evtchn loaded. I need to modprobe it manually, run xenstored
> manually and then after starting xen daemon the error of dom0 state
happens.
I suggest add some tracing to function dom0_init() in xenstored and see
where that function is failing. The two most obvious places were the opening
of those two files in /proc. If they exist then I''m not sure what else
could
be going wrong.

Oh, you should be able to cat /proc/xen/ksd_port and get an integer value.
/proc/xen/ksd_kva by contrast gets mmap()ed by xenstored.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 06:09 AM, Michal Novotny wrote:
> On 06/07/2010 01:39 PM, Keir Fraser wrote:
>> On 07/06/2010 12:21, "Michal
Novotny"<minovotn@redhat.com>  wrote:
>>
>>   
>>>
"/usr/lib64/python2.4/site-packages/xen/xend/xenstore/xsutil.py", line
>>> 18, in xshandle
>>>       xs_handle = xen.lowlevel.xs.xs()
>>> Error: (111, ''Connection refused'')
>>>
>>> Any guess what may be going wrong?
>>>      
>> Xenstored not running, or refusing connections for some other reason?
>>
>>   -- Keir
>>
>>
>>    
> Not running and refusing to run: FATAL: Failed to open evtchn device:
> No such file or directory
Make sure /dev/xen/evtchn exists.  If you''re running current libxc, it
will not longer automatically create it, but rely on your distro
mechanisms (typically udev) to create it for you.  It should be:

$ ls -l /dev/xen
[...]
crw-r-----. 1 root root  10, 61 2010-06-05 16:50 eventchn
crw-rw----. 1 root root  10, 61 2010-06-05 16:49 evtchn
crw-------. 1 root root  10, 60 2010-06-07 11:17 gntdev

(not sure why there''s the duplicate evtchn devices)


If you''re running an older libxc and a new pvops dom0, then it will get
it wrong and destroy your existing good devices and replace them with junk.

I should probably make sure the device name fix goes into .31 kernel as
well.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/07/2010 07:56 PM, Keir Fraser wrote:
> ...
> I suggest add some tracing to function dom0_init() in xenstored and see
> where that function is failing. The two most obvious places were the
opening
> of those two files in /proc. If they exist then I''m not sure what
else could
> be going wrong.
>
> Oh, you should be able to cat /proc/xen/ksd_port and get an integer value.
> /proc/xen/ksd_kva by contrast gets mmap()ed by xenstored.
>    
Are you sure it''s ksd_*? Isn''t it xsd_*?

This is what I''m having:

# ls /proc/xen
capabilities  privcmd  xenbus  xsd_kva  xsd_port
# cat /proc/xen/xsd_port
21
#cat /proc/xen/xsd_kva
0xffff8801e8414000
#

I was finally able to make it work. The main problem was absence of 
xen-evtchn module in memory which is why the xenstore daemon was unable 
to start so I created /etc/sysconfig/modules/xen.modules with the 
following contents:
#!/bin/sh
MODULES="xenfs xen-evtchn xen_evtchn"
for i in $MODULES ; do
         modprobe $i >/dev/null 2>&1
done

and after that when I rebooted the dom0 there was xen_evtchn in the 
`lsmod` output. Unfortunately the xenstore daemon was not running but 
when I run `xend start` it came online and `xm list` was showing at 
least dom0 (I had no other domain here so this is good) but after reboot 
I have to do following to make `xm list` show good data:

# lsmod | grep xen
xen_evtchn              8344  0
xenfs                  15624  1
# xend start
Nothing to flush.
# xm list
Name                                        ID   Mem VCPUs      State   
Time(s)
Domain-0                                     0  7453     4     
r-----     54.1
#

The daemon doesn''t start on boot although it''s trying to
start. I think
that the problem is that event channel module does get loaded into the 
memory after the xend is trying to start xenstore daemon (which is bad 
since xenstore daemon can''t start before event channel module) and 
itself which results into error in connection:

# xm list
Error: Unable to connect to xend: No such file or directory. Is xend 
running?
#

Now, when I''m having the working PVops kernel and tools running,
I''m
trying to get it start up a domain using `xm create HVMguest` and it 
returns:

[2010-06-08 13:58:24 5137] DEBUG (XendDomainInfo:103) 
XendDomainInfo.create([''vm'', [''name'',
''rhel5-32fv''], [''memory'', 1024],
[''maxmem'', 1024], [''on_poweroff'',
''destroy''], [''on_reboot'',
''restart''],
[''on_crash'', ''restart''],
[''on_xend_start'', ''ignore''],
[''on_xend_stop'',
''ignore''], [''vcpus'', 1],
[''uuid'',
''a21e0a64-8fbe-48c2-f28e-9c1cfc7427c7''],
[''oos'', 1], [''image'',
[''hvm'',
[''kernel'', ''/usr/lib/xen/boot/hvmloader''],
[''videoram'', 4], [''parallel'',
''none''], [''serial'',
''pty''], [''acpi'', 1],
[''apic'', 1], [''boot'',
''c''],
[''cpuid'', []], [''cpuid_check'', []],
[''device_model'',
''/usr/lib64/xen/bin/qemu-dm''], [''fda'',
''''], [''fdb'', ''''],
[''guest_os_type'', ''default''],
[''hap'', 1], [''hpet'', 0],
[''isa'', 0],
[''keymap'', ''en-us''],
[''localtime'', 0], [''nographic'', 0],
[''oos'', 1],
[''pae'', 1], [''pci'', []],
[''pci_msitranslate'', 1], [''pci_power_mgmt'',
0],
[''rtc_timeoffset'', 0], [''sdl'', 0],
[''soundhw'', ''''],
[''stdvga'', 0],
[''timer_mode'', 1], [''usb'', 0],
[''usbdevice'', ''''],
[''vcpus'', 1], [''vnc'',
1], [''vncdisplay'', 5], [''vncunused'', 0],
[''viridian'', 0], [''vpt_align'',
1], [''xauthority'', ''/root/.Xauthority''],
[''xen_platform_pci'', 1],
[''memory_sharing'', 0], [''tsc_mode'', 0],
[''nomigrate'', 0]]],
[''s3_integrity'', 1], [''device'',
[''vbd'', [''uname'',
''file:/var/lib/xen/images/colossus/rhel5-32fv.img''],
[''dev'', ''hda''],
[''mode'', ''w'']]],
[''device'', [''vbd'',
[''uname'', ''file:/home2/test.img''],
[''dev'', ''sda''], [''mode'',
''w'']]], [''device'', [''vif'',
[''bridge'', ''eth0''],
[''mac'', ''00:16:3e:6b:d5:c0''],
[''type'', ''netfront'']]]])
[2010-06-08 13:58:24 5137] DEBUG (XendDomainInfo:2510) 
XendDomainInfo.constructDomain
[2010-06-08 13:58:24 5137] DEBUG (balloon:187) Balloon: 638692 KiB free; 
need 16384; done.
[2010-06-08 13:58:24 5137] DEBUG (XendDomain:464) Adding Domain: 4
[2010-06-08 13:58:24 5137] DEBUG (XendDomainInfo:2848) 
XendDomainInfo.initDomain: 4 256
[2010-06-08 13:58:24 5137] DEBUG (image:339) No VNC passwd configured 
for vfb access
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: boot, val: c
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: fda, val: None
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: fdb, val: None
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: soundhw, val: None
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: localtime, val: 0
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: serial, val:
[''pty'']
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: std-vga, val: 0
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: isa, val: 0
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: acpi, val: 1
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: usb, val: 0
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: usbdevice, val: None
[2010-06-08 13:58:24 5137] DEBUG (image:889) args: gfx_passthru, val: None
[2010-06-08 13:58:24 5137] INFO (image:822) Need to create platform 
device.[domid:4]
[2010-06-08 13:58:24 5137] DEBUG (XendDomainInfo:2875) 
_initDomain:shadow_memory=0x0, memory_static_max=0x40000000, 
memory_static_min=0x0.
[2010-06-08 13:58:24 5137] DEBUG (balloon:172) Balloon: tmem 
relinquished 0 KiB of 431872 KiB requested.
[2010-06-08 13:58:24 5137] DEBUG (balloon:193) Balloon: 634112 KiB free; 
0 to scrub; need 1065984; retries: 20.
[2010-06-08 13:58:24 5137] DEBUG (balloon:207) Balloon: setting dom0 
target to 7524 MiB.
[2010-06-08 13:58:24 5137] DEBUG (XendDomainInfo:1479) Setting memory 
target of domain Domain-0 (0) to 7524 MiB.
[2010-06-08 13:58:24 5137] DEBUG (balloon:187) Balloon: 634112 KiB free; 
need 72704; done.
[2010-06-08 13:58:24 5137] DEBUG (balloon:193) Balloon: 634112 KiB free; 
0 to scrub; need 1065984; retries: 20.
[2010-06-08 13:58:47 5137] DEBUG (XendDomainInfo:1479) Setting memory 
target of domain Domain-0 (0) to 7945 MiB.
[2010-06-08 13:58:47 5137] DEBUG (balloon:187) Balloon: 634112 KiB free; 
need 431104; done.
[2010-06-08 13:58:47 5137] ERROR (XendDomainInfo:2934) 
XendDomainInfo.initDomain: exception occurred
Traceback (most recent call last):
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 2893, in _initDomain
     balloon.free(memory + shadow + vtd_mem, self)
   File "/usr/lib64/python2.4/site-packages/xen/xend/balloon.py", line
237, in free
     raise VmError(
VmError: Not enough memory is available, and dom0 cannot be shrunk any 
further
[2010-06-08 13:58:47 5137] ERROR (XendDomainInfo:485) VM start failed
Traceback (most recent call last):
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 471, in start
     XendTask.log_progress(31, 60, self._initDomain)
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendTask.py",
line
209, in log_progress
     retval = func(*args, **kwds)
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 2937, in _initDomain
     raise exn
VmError: Not enough memory is available, and dom0 cannot be shrunk any 
further
[2010-06-08 13:58:47 5137] DEBUG (XendDomainInfo:3083) 
XendDomainInfo.destroy: domid=4
[2010-06-08 13:58:47 5137] DEBUG (XendDomainInfo:2413) Destroying device 
model
[2010-06-08 13:58:47 5137] ERROR (XendDomainInfo:2416) Device model 
destroy failed X86_HVM_ImageHandler instance has no attribute 
''sentinel_lock''
Traceback (most recent call last):
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 2414, in _releaseDevices
     self.image.destroyDeviceModel()
   File "/usr/lib64/python2.4/site-packages/xen/xend/image.py", line 
621, in destroyDeviceModel
     self.sentinel_lock.acquire()
AttributeError: X86_HVM_ImageHandler instance has no attribute 
''sentinel_lock''
[2010-06-08 13:58:47 5137] DEBUG (XendDomainInfo:2420) Releasing devices
[2010-06-08 13:58:47 5137] ERROR (XendDomainInfo:108) Domain 
construction failed
Traceback (most recent call last):
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 106, in create
     vm.start()
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 471, in start
     XendTask.log_progress(31, 60, self._initDomain)
   File "/usr/lib64/python2.4/site-packages/xen/xend/XendTask.py",
line
209, in log_progress
     retval = func(*args, **kwds)
   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 2937, in _initDomain
     raise exn
VmError: Not enough memory is available, and dom0 cannot be shrunk any 
further

I also tried to decrease the memory for dom0 as advised on the list 
(using the `xm mem-set 0 2048`) but still the same result but I saw 
something in the qemu-dm log file about -vcpu-avail option is invalid:

# cat /var/log/xen/qemu-dm-rhel5-32fv.log
domid: 1
qemu: the number of cpus is 1
/usr/lib64/xen/bin/qemu-dm: invalid option -- ''-vcpu_avail''
#

Now I''m thinking whether there wasn''t a change of qemu-dm to
stubdom-dm.
Where is it located and could you provide me some example configuration 
file for xen-4.1-unstable?

Thanks,
Michal
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/08/2010 12:04 PM, Michal Novotny wrote:
> On 06/07/2010 07:56 PM, Keir Fraser wrote:
>> ...
>> I suggest add some tracing to function dom0_init() in xenstored and see
>> where that function is failing. The two most obvious places were the 
>> opening
>> of those two files in /proc. If they exist then I''m not sure
what
>> else could
>> be going wrong.
>>
>> Oh, you should be able to cat /proc/xen/ksd_port and get an integer 
>> value.
>> /proc/xen/ksd_kva by contrast gets mmap()ed by xenstored.
>
Thank you all, I was able to make it running (using some qemu-dm example 
in the example) at least for my testing of HVM guest read-only image 
handling fix (I didn''t try it for PV guests yet) and I have to confirm 
that my patch to fix read-only image file handling (sent to the list as 
the first e-mail in this thread) is working fine with both 
xen-3.4-testing and xen-4.1-unstable. The fix is for xen-iommu located 
in iommu-dir (downloaded from git). Is this the right list to post this 
patch to? It can''t be going to qemu-devel list since this is really 
closely connected to xenstore which is not a part of qemu at all so this 
is for the xenstore layer of qemu-dm mainly.

Thanks,
Michal

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 08/06/2010 11:39, "Michal Novotny" <minovotn@redhat.com>
wrote:
> Thank you all, I was able to make it running (using some qemu-dm example
> in the example) at least for my testing of HVM guest read-only image
> handling fix (I didn''t try it for PV guests yet) and I have to
confirm
> that my patch to fix read-only image file handling (sent to the list as
> the first e-mail in this thread) is working fine with both
> xen-3.4-testing and xen-4.1-unstable. The fix is for xen-iommu located
> in iommu-dir (downloaded from git). Is this the right list to post this
> patch to? It can''t be going to qemu-devel list since this is
really
> closely connected to xenstore which is not a part of qemu at all so this
> is for the xenstore layer of qemu-dm mainly.
Send it to this list as a patch to our qemu git repository. Cc Ian Jackson
who maintains that repo.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/08/2010 12:50 PM, Keir Fraser wrote:
> On 08/06/2010 11:39, "Michal Novotny"<minovotn@redhat.com> 
wrote:
>
>    
>> Thank you all, I was able to make it running (using some qemu-dm
example
>> in the example) at least for my testing of HVM guest read-only image
>> handling fix (I didn''t try it for PV guests yet) and I have to
confirm
>> that my patch to fix read-only image file handling (sent to the list as
>> the first e-mail in this thread) is working fine with both
>> xen-3.4-testing and xen-4.1-unstable. The fix is for xen-iommu located
>> in iommu-dir (downloaded from git). Is this the right list to post this
>> patch to? It can''t be going to qemu-devel list since this is
really
>> closely connected to xenstore which is not a part of qemu at all so
this
>> is for the xenstore layer of qemu-dm mainly.
>>      
> Send it to this list as a patch to our qemu git repository. Cc Ian Jackson
> who maintains that repo.
>
>   -- Keir
>
>    
I did already sent it to this list as a first e-mail in this thread. 
Should I repost the same version of the patch and just send it to Ian ?

Michal
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 08/06/2010 11:04, "Michal Novotny" <minovotn@redhat.com>
wrote:
> I also tried to decrease the memory for dom0 as advised on the list
> (using the `xm mem-set 0 2048`) but still the same result but I saw
> something in the qemu-dm log file about -vcpu-avail option is invalid:
> 
> # cat /var/log/xen/qemu-dm-rhel5-32fv.log
> domid: 1
> qemu: the number of cpus is 1
> /usr/lib64/xen/bin/qemu-dm: invalid option --
''-vcpu_avail''
> #
Stale qemu-dm binary hanging around, perhaps. I find that kind of thing
happens when trying out different version sof Xen on a single test system.
Either your new qemu-dm binary did not get installed, or it did but in a
different location to the stale one, and it happens that the stale one
dominates.

In particular, Xen 3.4 qemu does not support the -vcpu_avail cmdline option,
but 4.0 and 4.1 (unstable) do. And 4.0/4.1 xend depends on that.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/08/2010 12:53 PM, Keir Fraser wrote:
> On 08/06/2010 11:04, "Michal Novotny"<minovotn@redhat.com> 
wrote:
>
>    
>> I also tried to decrease the memory for dom0 as advised on the list
>> (using the `xm mem-set 0 2048`) but still the same result but I saw
>> something in the qemu-dm log file about -vcpu-avail option is invalid:
>>
>> # cat /var/log/xen/qemu-dm-rhel5-32fv.log
>> domid: 1
>> qemu: the number of cpus is 1
>> /usr/lib64/xen/bin/qemu-dm: invalid option --
''-vcpu_avail''
>> #
>>      
> Stale qemu-dm binary hanging around, perhaps. I find that kind of thing
> happens when trying out different version sof Xen on a single test system.
> Either your new qemu-dm binary did not get installed, or it did but in a
> different location to the stale one, and it happens that the stale one
> dominates.
>
> In particular, Xen 3.4 qemu does not support the -vcpu_avail cmdline
option,
> but 4.0 and 4.1 (unstable) do. And 4.0/4.1 xend depends on that.
>
>   -- Keir
>
>
>    
Ok, I did use some HVM example configuration file from the examples in 
the repo so I was able to make it working.

Michal

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 08/06/2010 11:52, "Michal Novotny" <minovotn@redhat.com>
wrote:
>> Send it to this list as a patch to our qemu git repository. Cc Ian
Jackson
>> who maintains that repo.
> 
> I did already sent it to this list as a first e-mail in this thread.
> Should I repost the same version of the patch and just send it to Ian ?
Yeah just chase him directly.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/08/2010 01:03 PM, Keir Fraser wrote:
> On 08/06/2010 11:52, "Michal Novotny"<minovotn@redhat.com> 
wrote:
>
>    
>>> Send it to this list as a patch to our qemu git repository. Cc Ian
Jackson
>>> who maintains that repo.
>>>        
>> I did already sent it to this list as a first e-mail in this thread.
>> Should I repost the same version of the patch and just send it to Ian ?
>>      
> Yeah just chase him directly.
>
>   -- Keir
>
>
>    
Oh, sorry, already posted to both list with all the information about 
possible behaviour when trying to mount image defined as read-only as a 
read-write (i.e. the error message) and some notes about it with CC to 
you and Ian.

Michal

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 8 Jun 2010, Keir Fraser wrote:
> On 08/06/2010 11:04, "Michal Novotny" <minovotn@redhat.com>
wrote:
>
>> I also tried to decrease the memory for dom0 as advised on the list
>> (using the `xm mem-set 0 2048`) but still the same result but I saw
>> something in the qemu-dm log file about -vcpu-avail option is invalid:
>>
>> # cat /var/log/xen/qemu-dm-rhel5-32fv.log
>> domid: 1
>> qemu: the number of cpus is 1
>> /usr/lib64/xen/bin/qemu-dm: invalid option --
''-vcpu_avail''
>> #
>
> Stale qemu-dm binary hanging around, perhaps. I find that kind of thing
> happens when trying out different version sof Xen on a single test system.
> Either your new qemu-dm binary did not get installed, or it did but in a
> different location to the stale one, and it happens that the stale one
> dominates.
>
> In particular, Xen 3.4 qemu does not support the -vcpu_avail cmdline
option,
> but 4.0 and 4.1 (unstable) do. And 4.0/4.1 xend depends on that.
qemu-dm was at /usr/lib64/xen/bin/qemu-dm in 3.4 on 64-bit builds but for 
some reason it moved to /usr/lib/xen/bin/qemu-dm in 4.0 and presumably 4.1.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 06/08/2010 01:11 PM, M A Young wrote:
>
> On Tue, 8 Jun 2010, Keir Fraser wrote:
>
>> On 08/06/2010 11:04, "Michal Novotny"
<minovotn@redhat.com> wrote:
>>
>>> I also tried to decrease the memory for dom0 as advised on the list
>>> (using the `xm mem-set 0 2048`) but still the same result but I saw
>>> something in the qemu-dm log file about -vcpu-avail option is
invalid:
>>>
>>> # cat /var/log/xen/qemu-dm-rhel5-32fv.log
>>> domid: 1
>>> qemu: the number of cpus is 1
>>> /usr/lib64/xen/bin/qemu-dm: invalid option --
''-vcpu_avail''
>>> #
>>
>> Stale qemu-dm binary hanging around, perhaps. I find that kind of thing
>> happens when trying out different version sof Xen on a single test 
>> system.
>> Either your new qemu-dm binary did not get installed, or it did but in
a
>> different location to the stale one, and it happens that the stale one
>> dominates.
>>
>> In particular, Xen 3.4 qemu does not support the -vcpu_avail cmdline 
>> option,
>> but 4.0 and 4.1 (unstable) do. And 4.0/4.1 xend depends on that.
>
> qemu-dm was at /usr/lib64/xen/bin/qemu-dm in 3.4 on 64-bit builds but 
> for some reason it moved to /usr/lib/xen/bin/qemu-dm in 4.0 and 
> presumably 4.1.
>
>     Michael Young
Oh, ok, thanks Michael. This way I can now understand why is was not 
working with "/usr/lib64/xen/bin/qemu-dm" but it''s working
with just
"qemu-dm" since "qemu-dm" makes the path of
"/usr/lib/xen/bin/qemu-dm".
In 4.1 it''s /usr/lib/xen/bin/qemu-dm too. When I tried to list it using
the `ps aux | grep qemu-dm` it was showing the difference here so if the 
path changed it makes sense now.

Thanks a lot,
Michal

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel