headers
Mathew Snyder | 1 Jul 01:07
Picon
Gravatar

Console Resolution

I've read numerous responses to this questions which simply state the 
solution as setting the vga=<resolution> parameter on the kernel boot 
line.  However, this has failed me.  The setting I have configured is 
vga=0x31A for 1280x1024.  However, it still loads as either 600x480 or 
800x600 (I'm not sure which, suffice it to say that it is wrong).

This has led to a related problem in that the cursor ends up below the 
bottom of the screen.  I have to clear the screen regularly to get it to 
the top.

Why doesn't Xen recognize the boot parameter?  Is there a separate 
configuration file I need to change for this?

Thanks,
Mathew
--

-- 
Keep up with my goings on at 
http://theillien.blogspot.com/feeds/posts/default
Permalink | Reply | 5 comments |
headers
Andy Burns | 1 Jul 01:10
Picon

Re: Unable to remove GPLPV drivers without breaking win2k3 domU - SUCCESS

On 30/06/2008 19:52, James Pifer wrote:

> DANG! 
> 
> In my case I have 0.8.8 loaded, but I'm not even loading /gplpv. I
> originally loaded it to get rid of the unknown PCI device, which it
> did. 

OK, I tried again and got it working with 0.9.10 instead of 0.9.11-pre4 
(though the version might not be significant)

I was a bit more fussy about what registry settings I kept and removed 
this time, also I think I didn't wait at the "grey progress screen" for 
long enough last time, it sticks there for what feels like two or three 
minutes.

So to summarise what I did ...

1) ensure domU will boot without /GPLPV

2) reboot into recovery console from windows CD (or ISO)

3) disable all xen services/drivers *except* xenhide

4) boot into windows, without /GPLPV

5) If any "hardware detected" dialogs are raised, cancel them, do not 
allow any xen drivers/services to be re-installed.

6) Start regedit
(Continue reading)

Permalink | Reply | 11 comments |
headers
James Pifer | 1 Jul 01:32

Re: Unable to remove GPLPV drivers without breaking win2k3 domU - SUCCESS

On Tue, 2008-07-01 at 00:10 +0100, Andy Burns wrote:
> On 30/06/2008 19:52, James Pifer wrote:
> 
> > DANG! 
> > 
> > In my case I have 0.8.8 loaded, but I'm not even loading /gplpv. I
> > originally loaded it to get rid of the unknown PCI device, which it
> > did. 
> 
> OK, I tried again and got it working with 0.9.10 instead of 0.9.11-pre4 
> (though the version might not be significant)
> 
> I was a bit more fussy about what registry settings I kept and removed 
> this time, also I think I didn't wait at the "grey progress screen" for 
> long enough last time, it sticks there for what feels like two or three 
> minutes.
> 
> So to summarise what I did ...
> 
> 1) ensure domU will boot without /GPLPV
> 
> 2) reboot into recovery console from windows CD (or ISO)
> 
> 3) disable all xen services/drivers *except* xenhide
> 
> 4) boot into windows, without /GPLPV
> 
> 5) If any "hardware detected" dialogs are raised, cancel them, do not 
> allow any xen drivers/services to be re-installed.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Elaine Cheong | 1 Jul 02:02
Picon
Favicon

cannot migrate vm back to original machine (currently with libvirt)

I posted the message below on the libvir-list with no replies, so  
perhaps someone on this list has some experience with this issue.   
Alternatively, if anyone has gotten remote migration to work with  
Fedora and Xen, could you please send me the version numbers you are  
using for each tool?  I've tried Xen API with this setup previously,  
but migration didn't work at all.

I am running Fedora 8 with Xen 3.1.2 and libvirt 0.4.3 on two machines  
(machine #1 and #2).  I am able to migrate it back from #1 to #2 by  
hand using "xm migrate -l <vmname> <ipaddress2>".  Any clues as to why  
I cannot migrate the VM back to the original machine with libvirt  
(details below)?

I am using the libvirt call virDomainMigrate() to migrate a VM from  
machine #2 (where it originally resides) to machine #1.  I am unable  
to migrate the VM back to machine #2 using virDomainMigrate(), even if  
I first migrate the VM from #2 to #1 by hand, using "xm migrate -l  
<vmname> <ipaddress1>".

When I make the call to virDomainMigrate(domain_to_migrate,  
connection_to_machine_2, VIR_MIGRATE_LIVE, NULL, NULL, 0), I get the  
following message:

libvir: Xen Daemon error : POST operation failed: xend_post: error  
from xen daemon: (xend.err "can't connect: Name or service not known")

I have tried running my program on both machine #2 (connecting to  
machine #1 with ssh, and machine #2 with local (NULL) or ssh), and on  
a separate 3rd machine (connecting to machine #1 and #2 with ssh), but  
I get the same error message in both cases.  I've tried connecting
(Continue reading)

Permalink | Reply | 0 comments |
headers
jim burns | 1 Jul 03:28

Re: Console Resolution

On Monday June 30 2008 07:07:55 pm Mathew Snyder wrote:
> I've read numerous responses to this questions which simply state the
> solution as setting the vga=<resolution> parameter on the kernel boot
> line.  However, this has failed me.  The setting I have configured is
> vga=0x31A for 1280x1024.  However, it still loads as either 600x480 or
> 800x600 (I'm not sure which, suffice it to say that it is wrong).

See this thread from Keir Fraser:

http://lists.xensource.com/archives/html/xen-devel/2008-05/msg00572.html
Permalink | Reply | 4 comments |
headers
James Harper | 1 Jul 04:58
Picon

RE: Unable to remove GPLPV drivers without breaking win2k3domU

> 
> attempt 1 - installed new drivers over the top of the old ones, got
> bluescreen at next boot.
> 
> attempt 2 - restored disk and used the un-install.bat from the old
> version, still bluescreen at next boot.
> 
> attempt 3 - manually uninstalled all xen devices from within device
> manager, deleted all relevant .inf/.pnf/.sys files, it still
> bluescreens, I think it's a STOP 0x0000007B
> 
> Any more suggestions on how to remove the old drivers and keep it
> bootable, ready to try the newer version?
> 

I have documented this on the wiki -
http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing

It's probably the upper and lower filter entries in the registries that
are biting you - if xenhide.sys is an upper or lower filter anywhere (eg
on the pci bus) then that driver won't load (because you deleted it),
and obviously if the pci bus doesn't get loaded then nothing good is
going to happen.

James
Permalink | Reply | 0 comments |
headers
James Harper | 1 Jul 04:59
Picon

RE: Unable to remove GPLPV drivers without breaking win2k3domU - SUCCESS

> On 30/06/2008 19:52, James Pifer wrote:
> 
> > DANG!
> >
> > In my case I have 0.8.8 loaded, but I'm not even loading /gplpv. I
> > originally loaded it to get rid of the unknown PCI device, which it
> > did.
> 
> OK, I tried again and got it working with 0.9.10 instead of
0.9.11-pre4
> (though the version might not be significant)
> 
> I was a bit more fussy about what registry settings I kept and removed
> this time, also I think I didn't wait at the "grey progress screen"
for
> long enough last time, it sticks there for what feels like two or
three
> minutes.
> 
> So to summarise what I did ...
> 
> 1) ensure domU will boot without /GPLPV
> 
> 2) reboot into recovery console from windows CD (or ISO)
> 
> 3) disable all xen services/drivers *except* xenhide
> 
> 4) boot into windows, without /GPLPV
> 
> 5) If any "hardware detected" dialogs are raised, cancel them, do not
(Continue reading)

Permalink | Reply | 6 comments |
headers
Fajar A. Nugraha | 1 Jul 05:02

Re: Startup-Hook Script ?

Steffen Heil wrote:
>   
>> For example this is my iscsi script:
>>
>> http://kinkrsoftware.nl/contrib/xen/block-iscsi
>>
>> If you do file based stuff I suggest you to look at a wrapper 
>> around tap:aio://
>>     
>
> As I use "phy:" for my devices, I added a script "block-boot-phy" as a copy
> of block and modified it to copy the kernel out of the device that was
> attached using "boot-phy:" and this works.
>
> But it works too late. The kernel or initrd is already loaded at that point.
>
>   

Since function-wise you're trying to achieve what pygrub does, it might 
be easier to create another pygrub-like script and put it as bootloader 
on your config file.

for example, pygrub takes these parameters :
/usr/bin/pygrub [-q|--quiet] [-i|--interactive] [--output=] [--kernel=] 
[--ramdisk=] [--args=] [--entry=] <image>

when used as bootloader on domU config file, pygrub will be invoked with 
something like
pygrub --output=/var/run/xend/boot/xenbl.3079 /dev/rootvg/testlv
(Continue reading)

Permalink | Reply | 2 comments |
headers
Todd Deshane | 1 Jul 07:26
Picon
Gravatar

Re: Problem iscsi on domU



On Mon, Jun 30, 2008 at 5:46 AM, Lino Moragon <lino.moragon <at> highspeed.li> wrote:
Hi list,

I'm having troubles to get an iscsi initiator working on a domU.
As dom0 and domU I use a Centos 5 with the 2.6.18-53.1.14.el5 xen-kernel.
As iscsi initiator i use the iscsi-initiator-utils of the Centos5 repo.
The problem is, that when I log in to my iscsi target on the domU it is recognized as /dev/sda1.
Now sda1 is also my root partition on the domU. And when I mount it I've mounted the root partition and not the iscsi device.

Has anyone had this problem yet? Is there a solution to make it recognized as e.g. /dev/sdb ?

Any help and tips would be appreciated.

You should be able to setup a udev rule that will recognize the drives and correctly set them up.

take a look here:
http://www.performancemagic.com/iscsi-xen-howto/iSCSI.html

Cheers,
Todd
_______________________________________________
Xen-users mailing list
Xen-users <at> lists.xensource.com
http://lists.xensource.com/xen-users
Permalink | Reply | 5 comments |
headers
Lino Moragon | 1 Jul 08:36
Picon
Favicon

Re: Problem iscsi on domU

Todd Deshane wrote:
>
>
> On Mon, Jun 30, 2008 at 5:46 AM, Lino Moragon 
> <lino.moragon <at> highspeed.li <mailto:lino.moragon <at> highspeed.li>> wrote:
>
>     Hi list,
>
>     I'm having troubles to get an iscsi initiator working on a domU.
>     As dom0 and domU I use a Centos 5 with the 2.6.18-53.1.14.el5
>     xen-kernel.
>     As iscsi initiator i use the iscsi-initiator-utils of the Centos5
>     repo.
>     The problem is, that when I log in to my iscsi target on the domU
>     it is recognized as /dev/sda1.
>     Now sda1 is also my root partition on the domU. And when I mount
>     it I've mounted the root partition and not the iscsi device.
>
>     Has anyone had this problem yet? Is there a solution to make it
>     recognized as e.g. /dev/sdb ?
>
>     Any help and tips would be appreciated.
>
>
> You should be able to setup a udev rule that will recognize the drives 
> and correctly set them up.
>
> take a look here:
> http://www.performancemagic.com/iscsi-xen-howto/iSCSI.html
Hi,

Thanks for your response. I just tried it that way.
Only problem is, that it creates a link that links to the same /dev/sda1.
So if I mount the new /dev/iscsi_11 device it will mount again the root 
filesystem.
Are there other possible options? Or isn't it at all possible?

Thanks for some hints.

Regards, Lino
Permalink | Reply | 4 comments |

Gmane