[PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

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

[-- Attachment #2: xen-qemu-fix-readonly-image-handling.patch --]
[-- Type: text/x-patch, Size: 6435 bytes --]

commit 38dffb8e986167c363f24fd770d77cbe3957f34c
Author: Michal Novotny <minovotn@redhat.com>
Date:   Thu Jun 3 15:44:31 2010 +0200

    qemu-xen: Fix read-only image file handling
    
    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. The
    patch is applicable to qemu-xen-unstable.git as well with no
    modifications.
    
    Michal
    
    Signed-off-by: Michal Novotny <minovotn@redhat.com>

diff --git a/block.c b/block.c
index 88e70d3..05ff8cb 100644
--- a/block.c
+++ b/block.c
@@ -422,7 +422,7 @@ int bdrv_open2(BlockDriverState *bs, const char *filename, int flags,
     /* Note: for compatibility, we open disk image files as RDWR, and
        RDONLY as fallback */
     if (!(flags & BDRV_O_FILE))
-        open_flags = BDRV_O_RDWR | (flags & BDRV_O_CACHE_MASK);
+        open_flags = (flags & BDRV_O_ACCESS) | (flags & BDRV_O_CACHE_MASK);
     else
         open_flags = flags & ~(BDRV_O_FILE | BDRV_O_SNAPSHOT);
     ret = drv->bdrv_open(bs, filename, open_flags);
diff --git a/hw/ide.c b/hw/ide.c
index b38de55..791666b 100644
--- a/hw/ide.c
+++ b/hw/ide.c
@@ -2551,6 +2551,15 @@ static void ide_ioport_write(void *opaque, uint32_t addr, uint32_t val)
         case WIN_WRITE_ONCE:
         case CFA_WRITE_SECT_WO_ERASE:
         case WIN_WRITE_VERIFY:
+            if (bdrv_is_read_only(s->bs)) {
+#if defined(DEBUG_IDE)
+                printf("Attempt to write on read-only device %s\n", s->bs->filename);
+#endif
+                s->status = WRERR_STAT;
+                s->error = ABRT_ERR;
+                ide_set_irq(s);
+                break;
+            }
 	    ide_cmd_lba48_transform(s, lba48);
             s->error = 0;
             s->status = SEEK_STAT | READY_STAT;
@@ -2573,6 +2582,15 @@ static void ide_ioport_write(void *opaque, uint32_t addr, uint32_t val)
         case CFA_WRITE_MULTI_WO_ERASE:
             if (!s->mult_sectors)
                 goto abort_cmd;
+	    if (bdrv_is_read_only(s->bs)) {
+#if defined(DEBUG_IDE)
+                printf("Attempt to multiwrite on read-only device %s\n", s->bs->filename);
+#endif
+                s->status = WRERR_STAT;
+                s->error = ABRT_ERR;
+                ide_set_irq(s);
+                break;
+	    }
 	    ide_cmd_lba48_transform(s, lba48);
             s->error = 0;
             s->status = SEEK_STAT | READY_STAT;
@@ -2598,6 +2616,15 @@ static void ide_ioport_write(void *opaque, uint32_t addr, uint32_t val)
         case WIN_WRITEDMA_ONCE:
             if (!s->bs)
                 goto abort_cmd;
+            if (bdrv_is_read_only(s->bs)) {
+#if defined(DEBUG_IDE)
+                printf("Attempt to DMA write to read-only device %s\n", s->bs->filename);
+#endif
+                s->status = WRERR_STAT;
+                s->error = ABRT_ERR;
+                ide_set_irq(s);
+                break;
+            }
 	    ide_cmd_lba48_transform(s, lba48);
             ide_sector_write_dma(s);
             s->media_changed = 1;
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 9745ca3..db808d4 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -35,6 +35,7 @@ do { fprintf(stderr, "scsi-disk: " fmt , ##args); } while (0)
 #define SENSE_NOT_READY       2
 #define SENSE_HARDWARE_ERROR  4
 #define SENSE_ILLEGAL_REQUEST 5
+#define SENSE_DATA_PROTECT    7
 
 #define STATUS_GOOD            0
 #define STATUS_CHECK_CONDITION 2
@@ -234,6 +235,9 @@ static int scsi_handle_write_error(SCSIRequest *r, int error)
             || action == BLOCK_ERR_STOP_ANY) {
         r->status |= SCSI_REQ_STATUS_RETRY;
         vm_stop(0);
+    } else if (error == SENSE_DATA_PROTECT) {
+        scsi_command_complete(r, STATUS_CHECK_CONDITION,
+                SENSE_DATA_PROTECT);
     } else {
         scsi_command_complete(r, STATUS_CHECK_CONDITION,
                 SENSE_HARDWARE_ERROR);
@@ -305,6 +309,11 @@ static int scsi_write_data(SCSIDevice *d, uint32_t tag)
         return 1;
     }
 
+    if (bdrv_is_read_only(r->dev->bdrv)) {
+        scsi_write_complete(r, SENSE_DATA_PROTECT);
+        return 1;
+    }
+
     if (r->aiocb)
         BADF("Data transfer already in progress\n");
 
diff --git a/xenstore.c b/xenstore.c
index b6d86ce..94ee0e2 100644
--- a/xenstore.c
+++ b/xenstore.c
@@ -343,6 +343,11 @@ void xenstore_parse_domain_config(int hvm_domid)
     BlockDriverState *bs;
     BlockDriver *format;
 
+    /* Read-only handling for image files */
+    char *mode = NULL;
+    int flags;
+    int is_readonly;
+
     /* paths controlled by untrustworthy guest, and values read from them */
     char *danger_path;
     char *danger_buf = NULL;
@@ -532,7 +537,24 @@ void xenstore_parse_domain_config(int hvm_domid)
 		}
 	    }
             pstrcpy(bs->filename, sizeof(bs->filename), params);
-            if (bdrv_open2(bs, params, BDRV_O_CACHE_WB /* snapshot and write-back */, format) < 0)
+
+            flags = BDRV_O_CACHE_WB; /* snapshot and write-back */
+            is_readonly = 0;
+            if (pasprintf(&buf, "%s/mode", bpath) == -1)
+                continue;
+            free(mode);
+            mode = xs_read(xsh, XBT_NULL, buf, &len);
+            if (mode == NULL)
+                continue;
+            if (strchr(mode, 'r') && !strchr(mode, 'w'))
+                is_readonly = 1;
+
+            if (!is_readonly)
+                flags |= BDRV_O_ACCESS & O_RDWR;
+
+            fprintf(stderr, "Using file %s in read-%s mode\n", bs->filename, is_readonly ? "only" : "write");
+
+            if (bdrv_open2(bs, params, flags, format) < 0)
                 fprintf(stderr, "qemu: could not open vbd '%s' or hard disk image '%s' (drv '%s' format '%s')\n", buf, params, drv ? drv : "?", format ? format->format_name : "0");
         }
 
@@ -679,6 +701,7 @@ void xenstore_parse_domain_config(int hvm_domid)
 
  out:
     free(danger_type);
+    free(mode);
     free(params);
     free(dev);
     free(bpath);

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Pasi Kärkkäinen]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Keir Fraser]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Pasi Kärkkäinen]

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
>

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Keir Fraser]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Pasi Kärkkäinen]

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
>

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Pasi Kärkkäinen]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Pasi Kärkkäinen]

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
>

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[M A Young]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Keir Fraser]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Pasi Kärkkäinen]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Pasi Kärkkäinen]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[M A Young]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Konrad Rzeszutek Wilk]

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.

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Keir Fraser]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Keir Fraser]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Jeremy Fitzhardinge]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Keir Fraser]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Keir Fraser]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Keir Fraser]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[M A Young]

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

Re: [PATCH] qemu-xen-3.4-testing: Fix read-only image file handling

[Michal Novotny]

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