# [Solved] Issue with Xen >4.2 and HVM hosts

## MasterPrenium

Hi guys,

I'm setting up a new gentoo server (quite minimalist for the moment) that's gonna run Xen.

I'm successfully able to run a gentoo VM on this server (following the gentoo Wiki).

Everything seems to run fine also on Xen 4.2.5, but issue while trying with Xen 4.5.1/4.5.2-r1

But I'm unable to start a windows VM, crashing while creating.

# xl dmesg

 *Quote:*   

>  Xen 4.5.2
> 
> (XEN) Xen version 4.5.2 (@(none)) (x86_64-pc-linux-gnu-gcc (Gentoo 4.8.5 p1.3, pie-0.6.2) 4.8.5) debug=n Wed Dec  2 19:24:15  2015
> 
> (XEN) Latest ChangeSet: 
> ...

 

# emerge --info xen xen-tools

 *Quote:*   

> Portage 2.2.20.1 (python 3.4.1-final-0, default/linux/amd64/13.0, gcc-4.8.5, glibc-2.20-r2, 4.0.5-gentoo x86_64)
> 
> =================================================================
> 
>                          System Settings
> ...

 

Example config not working as a test :

 *Quote:*   

> builder='hvm'
> 
> memory = 2457
> 
> vcpus = 4
> ...

 

# cat /var/log/xen/xl-windows-vm.log 

 *Quote:*   

> Waiting for domain windows-vm (domid 5) to die [pid 4374]
> 
> libxl: debug: libxl_event.c:581:libxl__ev_xswatch_register: watch w=0x25a7c68 wpath=@releaseDomain token=3/0: register slotnum=3
> 
> libxl: debug: libxl_event.c:581:libxl__ev_xswatch_register: watch w=0x25a4f50 wpath=/local/domain/5/device/vbd/5632/eject token=2/1: register slotnum=2
> ...

 

# cat /var/log/xen/qemu-dm-windows-vm.log 

 *Quote:*   

> char device redirected to /dev/pts/2 (label serial0)
> 
> qemu: terminating on signal 1 from pid 4374

 

Any idea on how to fix it ? Any help would be greatly appreciated.

Thanks !Last edited by MasterPrenium on Sun Dec 06, 2015 4:10 pm; edited 1 time in total

----------

## Atom2

MasterPrenium,

your issue is not at all related to the XEN version you are using. If you again decided to downgrade to version 4.2.5 now, you would exactly face the same issues. The problem is rather a corrupt version of SeaBIOS which you must avoid. You can easily solve this by performing the following steps:

1.) add the following line to your package.mask (file or directory):

```
=sys-firmware/seabios-1.8.2
```

2.) re-emerge sys-firmware/seabios which will result in a downgrade from version 1.8.2 to version 1.7.5

```
emerge -1 -av sys-firmware/seabios
```

3.) re-emerge app-emulation/xen-tools

```
emerge -1 -av app-emulation/xen-tools
```

4.) start your HVM and enjoy (there's no need to re-boot the system as long as you have started the machine under XEN)

Good luck Atom2

----------

## TigerJr

Do you have net.xenbr0 started in default runlevel? Did you try to start VM without vif interface?? What kernel xen backend drivers are you use??

----------

## MasterPrenium

Hi guys,

Thanks @Atom2 for the tweak, if seabios is corrupted, it should be hardmasked no ?

- app-emulation/xen-4.2.5-r12 was working great with =seabios-1.8.2

- Downgrading seabios to <1.8.2 solve the issue with xen >=4.5.2, thanks !

@TigerJr : nothing linked to the network and/or bridge.

----------

## Atom2

 *MasterPrenium wrote:*   

> - app-emulation/xen-4.2.5-r12 was working great with =seabios-1.8.2

 Unfortunately it did not work; you just did not notice it. The issue is rather more complex than you might think because with XEN there's no direct link to the installed version of SeaBIOS and there's also no dependency that would automatically re-install xen-tools whenever SeaBIOS changes.

In other words XEN uses the version of SeaBIOS available in the system at the time of its emerge. At the time xen-tools-4.2.5 was current, seabios-1.7.5 was the current version and thus it was used. The upgrade to seabios-1.8.2 did NOT have any impact on xen-tools-4.2.5 (i.e. it was not re-emerged) and therefore that change went unnoticed. Only when xen-tools-4.5.2 went stable it used the then current version of SeaBIOS, which was 1.8.2, and the disaster started from there. You can easily check this by again unmasking seabios-1.8.2, re-emerging seabios and xen-tools-4.2.5 and you will immediatley see that this version will also fail with an identical error message.

This is basically due to the fact that the current version of SeaBIOS installed on the system is being embedded in the binary hvmloader file during the emerge of xen-tools. The binary hvmloader is basically only required to start up xen HVM domUs. This is also the reason why PV domUs were not affected by that problem at all.

Atom2

----------

## TigerJr

 *Quote:*   

> USE=system-seabios emerge xen-tools

 

Doesn't worked? Cause xen-tools have his own seabios...

----------

## Atom2

 *TigerJr wrote:*   

>  *Quote:*   USE=system-seabios emerge xen-tools 
> 
> Doesn't worked? Cause xen-tools have his own seabios...

 TigerJr ... trust, me the problem is exactly as described above. Just try it out ...

Whilst in fact you are right that XEN does have it's own (bundled) SeaBIOS version, it is actually sys-firmware/seabios that's being used when you add the USE flag system-seabios as suggested by you above: In that case the ebuild simply uses sys-firmware/seabios instead of the bundled version during the build of xen-tools. And that package (in version 1.8.2) is simply borked.

If xen-tools, or more specifically the hvmloader binary file, had not used sys-firmware/seabios a downgrade from 1.8.2 to 1.7.5 of that package (with a re-emerge of xen-tools) wouldn't have had any impact at all.

The reason I am not using the bundled version of SeaBIOS anymore (I originally started off with the bundled version in 2013) and have had to switch over to the system-seabios (i.e. the package that is pulled in when you specify the USE flag system-seabios) is that the seabios bundled with XEN (after an upgrade of xen-tools already some time ago) was unable to boot a HVM domU running FreeBSD from a GPT partition. With system-seabios that problem vanished and I was again able to start that domU and from that point on I decided to stick to the official sys-firmware/seabios.

Version 1.7.5 of sys-firmware/seabios was also just a simple download of the binary build from their official repository whereas for version 1.8.2 there's no such official binary version available to download from the repositories so it has to be built somewhere else. Furthermore version 1.7.5 was 256kb in size whereas version 1.8.2 is only 128kb (exactly half the size) which doesn't make any sense and is probably the root of the error. In any case, there's definitely something badly wrong with sys-firmware/seabios-1.8.2.

Atom2

----------

## TigerJr

 *Quote:*   

> With system-seabios that problem vanished and I was again able to start that domU and from that point on I decided to stick to the official sys-firmware/seabios. 
> 
>  Version 1.7.5 of sys-firmware/seabios was also just a simple download of the binary build from their official repository whereas for version 1.8.2 there's no such official binary version available to download from the repositories so it has to be built somewhere else. Furthermore version 1.7.5 was 256kb in size whereas version 1.8.2 is only 128kb (exactly half the size) which doesn't make any sense and is probably the root of the error. In any case, there's definitely something badly wrong with sys-firmware/seabios-1.8.2.

 

Interesting thing you are writing. But how it can be that seabios 1.8.2 not tested but has stable keywords otherwise 1.7.5-r1?

https://packages.gentoo.org/packages/sys-firmware/seabios

----------

