Re: HEADS UP: Imported Xen 4.7: no blkback

2016-06-16 Thread Marcin Cieslak 
On Thu, 16 Jun 2016, Roger Pau Monné wrote:

> I've just imported Xen 4.7.0-rc6 into the ports tree, could you give it a 
> try when you have a moment?

Yes, of course. A quick test shows no change - Windows get stuck
at the UEFI shell with some block devices listed (I use "hda" for
Windows), SeaBIOS cannot boot FreeBSD with "xvda". FreeBSD
works with "hda", but I have to mount "/dev/ada0p1".

Marcin
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7: no blkback

2016-06-16 Thread Roger Pau Monné 
On Mon, Jun 13, 2016 at 07:26:30PM +, Marcin Cieslak wrote:
> On Mon, 13 Jun 2016, Roger Pau Monné wrote:
> 
> > On Fri, Jun 10, 2016 at 09:38:59PM +, Marcin Cieslak wrote:
> > > "?" does not work - it mostly causes a panic, the console is slow, but I 
> > > managed
> > > to switch it to /dev/ada0p2, dmesg below:
> > 
> > This has now been reverted, so when I import the new RC this should be 
> > fixed 
> > and you won't need to change anything.
> 
> I am confused now - so with a new Xen kernel (not yet in ports) I can use
> /dev/xbd* devices again? They are in fact missing - xbd driver says 
> "attaching as ada0"
> and I can mount it only as /dev/ada
> 
> > It seems like Windows PV drivers don't attach at all, or are you running 
> > Windows without the PV drivers?
> 
> Yes, I have. Those Windows partitions used to work properly without changes
> under xen 4.5. But we are too early - the problem is that even ovmf
> does not se them drives now, this is before Windows boots.
> 
> > Since you mention that the console is very slow, if you run 'top' on Dom0, 
> > do you see any process (eg: qemu) taking a lot of CPU time?
> 
> Yes,
> 
>  1635 root  7 1000   241M   101M RUN  7:16  91.14% 
> qemu-system-i386
> 
> or more
> 
> > Also, do you see Dom0 consuming a lot of CPU if you run 'xentop'?
> 
>   Domain-0 -r446  100.04194300   25.2   no limit   n/a
>  10000000  0  
> 00
> 

Hello,

I've just imported Xen 4.7.0-rc6 into the ports tree, could you give it a 
try when you have a moment?

FWIW, I'm going on vacations until the 4th of July, and I will be mostly 
AFK.

Roger.
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7: no blkback

2016-06-13 Thread Marcin Cieslak 
On Mon, 13 Jun 2016, Roger Pau Monné wrote:

> On Fri, Jun 10, 2016 at 09:38:59PM +, Marcin Cieslak wrote:
> > "?" does not work - it mostly causes a panic, the console is slow, but I 
> > managed
> > to switch it to /dev/ada0p2, dmesg below:
> 
> This has now been reverted, so when I import the new RC this should be fixed 
> and you won't need to change anything.

I am confused now - so with a new Xen kernel (not yet in ports) I can use
/dev/xbd* devices again? They are in fact missing - xbd driver says "attaching 
as ada0"
and I can mount it only as /dev/ada

> It seems like Windows PV drivers don't attach at all, or are you running 
> Windows without the PV drivers?

Yes, I have. Those Windows partitions used to work properly without changes
under xen 4.5. But we are too early - the problem is that even ovmf
does not se them drives now, this is before Windows boots.

> Since you mention that the console is very slow, if you run 'top' on Dom0, 
> do you see any process (eg: qemu) taking a lot of CPU time?

Yes,

 1635 root  7 1000   241M   101M RUN  7:16  91.14% 
qemu-system-i386

or more

> Also, do you see Dom0 consuming a lot of CPU if you run 'xentop'?

  Domain-0 -r446  100.04194300   25.2   no limit   n/a 
10000000  0  0  
  0

Marcin
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7: no blkback

2016-06-13 Thread Marcin Cieslak 
On Mon, 13 Jun 2016, Roger Pau Monné wrote:

> Since you mention that the console is very slow, if you run 'top' on Dom0, 
> do you see any process (eg: qemu) taking a lot of CPU time?
> 
> Also, do you see Dom0 consuming a lot of CPU if you run 'xentop'?

Just quick info regarding console problem at the mountroot prompt:

- it was also very slow and behaving strange with older kernel
and 4.5.2.

- it works better when I use dual console - one can type on the 
serial console and see the results immediately, vidconsole
is slower but thins seem to work (at least I get no panics
due to "cannot mount root" anymore).

- will check top

Marcin
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7: no blkback

2016-06-13 Thread Roger Pau Monné 
On Fri, Jun 10, 2016 at 09:38:59PM +, Marcin Cieslak wrote:
> On Thu, 9 Jun 2016, Roger Pau Monné wrote:
> 
> > On Thu, Jun 09, 2016 at 12:16:59AM +, Marcin Cieslak wrote:
> > > On Fri, 3 Jun 2016, Roger Pau Monné wrote:
> > > 
> > > > One of the more relevant changes in 4.7 regarding FreeBSD is the 
> > > > support for 
> > > > block hotplug scripts. This means that we now have the option to use 
> > > > backends different than simple block or regular files, provided that 
> > > > someone 
> > > > writes the proper hotplug scripts to attach them (I've heard there are 
> > > > some 
> > > > iSCSI hotplug scripts around). This however requires changes in 
> > > > blkback, so 
> > > > if you plan to use the Xen 4.7 port, please make sure that you are 
> > > > running a 
> > > > kernel that contains revision r301269 (or any later version). The same 
> > > > also 
> > > 
> > > I am running it with r301685 and the HVM guests have some trouble with
> > > block devices.
> > > 
> > > SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD
> > > from, after chaging to "hda" I get up to the kernel mountroot prompt
> > > (Xen block devices seem to be detected in dmesg).
> > 
> > Yes, this is intentional, see:
> > 
> > https://marc.info/?l=xen-devel=144482080812353
> 
> those guests worked fine with 4.5, that's why I am surprised.
> 
> xbd0 and xbd1 show up in dmesg, mouting root from xbd0p2 fails, but 
> ada0p2 seems to work.
> 
> I remember that during my previous attempts ZFS ate most of
> my machine's memory (dom0 was too small I think) and the
> symptom was very similar if not identical.
> 
> One thing which struck me is that I was able to fully but
> one Linux HVM domU. I am also toying with OpenFirmware
> which boots from floppy as a HVM guest.
> 
> > Have you checked if you need to change your /etc/fstab to correctly point 
> > to the new device? Does FreeBSD correctly list the disk(s) at the mountroot 
> > prompt when issuing a "?" command?
> 
> "?" does not work - it mostly causes a panic, the console is slow, but I 
> managed
> to switch it to /dev/ada0p2, dmesg below:

This has now been reverted, so when I import the new RC this should be fixed 
and you won't need to change anything.
 
> Copyright (c) 1992-2016 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>   The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 11.0-CURRENT #1 r298620: Tue Apr 26 13:21:50 UTC 2016
> r...@o.saper.info:/usr/obj/usr/src/sys/GENERIC amd64
> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
> 3.8.0)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(vga): text 80x25
> XEN: Hypervisor version 4.7 detected.
> CPU: Intel(R) Xeon(R) CPU E31245 @ 3.30GHz (3300.08-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
>   
> Features=0x17c3fbff
>   
> Features2=0x9fba2203
>   AMD Features=0x28100800
>   AMD Features2=0x1
>   XSAVE Features=0x1
> Hypervisor: Origin = "XenVMMXenVMM"
> real memory  = 2130706432 (2032 MB)
> avail memory = 2018213888 (1924 MB)
> Event timer "LAPIC" quality 400
> ACPI APIC Table: 
> WARNING: L1 data cache covers less APIC IDs than a core
> 0 < 1
> WARNING: L2 data cache covers less APIC IDs than a core
> 0 < 1
> WARNING: L3 data cache covers less APIC IDs than a core
> 0 < 1
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> FreeBSD/SMP: 1 package(s) x 2 core(s)
> random: unblocking device.
> ioapic0: Changing APIC ID to 1
> MADT: Forcing active-low polarity and level trigger for SCI
> ioapic0  irqs 0-47 on motherboard
> random: entropy device external interface
> kbd1 at kbdmux0
> netmap: loaded module
> module_register_init: MOD_LOAD (vesa, 0x80f0ffb0, 0) error 19
> vtvga0:  on motherboard
> cryptosoft0:  on motherboard
> acpi0:  on motherboard
> acpi0: Power Button (fixed)
> acpi0: Sleep Button (fixed)
> cpu0:  on acpi0
> cpu1:  on acpi0
> hpet0:  iomem 0xfed0-0xfed003ff on acpi0
> Timecounter "HPET" frequency 6250 Hz quality 950
> attimer0:  port 0x40-0x43 irq 0 on acpi0
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Event timer "i8254" frequency 1193182 Hz quality 100
> atrtc0:  port 0x70-0x71 irq 8 on acpi0
> Event timer "RTC" frequency 32768 Hz quality 0
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0
> pcib0:  port 0xcf8-0xcff on acpi0
> pci0:  on pcib0
> isab0:  at device 1.0 on pci0
> isa0:  on isab0
> atapci0:  port 
> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc200-0xc20f at device 1.1 on pci0
> ata0:  at channel 0 on atapci0
>

Re: HEADS UP: Imported Xen 4.7: no blkback

2016-06-10 Thread Marcin Cieslak 
On Thu, 9 Jun 2016, Roger Pau Monné wrote:

> On Thu, Jun 09, 2016 at 12:16:59AM +, Marcin Cieslak wrote:
> > On Fri, 3 Jun 2016, Roger Pau Monné wrote:
> > 
> > > One of the more relevant changes in 4.7 regarding FreeBSD is the support 
> > > for 
> > > block hotplug scripts. This means that we now have the option to use 
> > > backends different than simple block or regular files, provided that 
> > > someone 
> > > writes the proper hotplug scripts to attach them (I've heard there are 
> > > some 
> > > iSCSI hotplug scripts around). This however requires changes in blkback, 
> > > so 
> > > if you plan to use the Xen 4.7 port, please make sure that you are 
> > > running a 
> > > kernel that contains revision r301269 (or any later version). The same 
> > > also 
> > 
> > I am running it with r301685 and the HVM guests have some trouble with
> > block devices.
> > 
> > SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD
> > from, after chaging to "hda" I get up to the kernel mountroot prompt
> > (Xen block devices seem to be detected in dmesg).
> 
> Yes, this is intentional, see:
> 
> https://marc.info/?l=xen-devel=144482080812353

those guests worked fine with 4.5, that's why I am surprised.

xbd0 and xbd1 show up in dmesg, mouting root from xbd0p2 fails, but 
ada0p2 seems to work.

I remember that during my previous attempts ZFS ate most of
my machine's memory (dom0 was too small I think) and the
symptom was very similar if not identical.

One thing which struck me is that I was able to fully but
one Linux HVM domU. I am also toying with OpenFirmware
which boots from floppy as a HVM guest.

> Have you checked if you need to change your /etc/fstab to correctly point 
> to the new device? Does FreeBSD correctly list the disk(s) at the mountroot 
> prompt when issuing a "?" command?

"?" does not work - it mostly causes a panic, the console is slow, but I managed
to switch it to /dev/ada0p2, dmesg below:

Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #1 r298620: Tue Apr 26 13:21:50 UTC 2016
r...@o.saper.info:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
3.8.0)
WARNING: WITNESS option enabled, expect reduced performance.
VT(vga): text 80x25
XEN: Hypervisor version 4.7 detected.
CPU: Intel(R) Xeon(R) CPU E31245 @ 3.30GHz (3300.08-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
  
Features=0x17c3fbff
  
Features2=0x9fba2203
  AMD Features=0x28100800
  AMD Features2=0x1
  XSAVE Features=0x1
Hypervisor: Origin = "XenVMMXenVMM"
real memory  = 2130706432 (2032 MB)
avail memory = 2018213888 (1924 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
WARNING: L1 data cache covers less APIC IDs than a core
0 < 1
WARNING: L2 data cache covers less APIC IDs than a core
0 < 1
WARNING: L3 data cache covers less APIC IDs than a core
0 < 1
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
random: unblocking device.
ioapic0: Changing APIC ID to 1
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0  irqs 0-47 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x80f0ffb0, 0) error 19
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
acpi0: Sleep Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 6250 Hz quality 950
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0:  port 0x70-0x71 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
isab0:  at device 1.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc200-0xc20f at device 1.1 on pci0
ata0:  at channel 0 on atapci0
ata1:  at channel 1 on atapci0
pci0:  at device 1.3 (no driver attached)
xenpci0:  port 0xc000-0xc0ff mem 0xf000-0xf0ff irq 
24 at device 2.0 on pci0
vgapci0:  mem 
0xf100-0xf1ff,0xf205-0xf2050fff at device 3.0 on pci0
vgapci0: Boot video device
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0:  irq 12 on atkbdc0
psm0:

Re: [Xen-devel] HEADS UP: Imported Xen 4.7: no blkback

2016-06-09 Thread Wei Liu 
On Thu, Jun 09, 2016 at 10:03:43AM +0200, Roger Pau Monné wrote:
> On Thu, Jun 09, 2016 at 12:16:59AM +, Marcin Cieslak wrote:
> > On Fri, 3 Jun 2016, Roger Pau Monné wrote:
> > 
> > > One of the more relevant changes in 4.7 regarding FreeBSD is the support 
> > > for 
> > > block hotplug scripts. This means that we now have the option to use 
> > > backends different than simple block or regular files, provided that 
> > > someone 
> > > writes the proper hotplug scripts to attach them (I've heard there are 
> > > some 
> > > iSCSI hotplug scripts around). This however requires changes in blkback, 
> > > so 
> > > if you plan to use the Xen 4.7 port, please make sure that you are 
> > > running a 
> > > kernel that contains revision r301269 (or any later version). The same 
> > > also 
> > 
> > I am running it with r301685 and the HVM guests have some trouble with
> > block devices.
> > 
> > SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD
> > from, after chaging to "hda" I get up to the kernel mountroot prompt
> > (Xen block devices seem to be detected in dmesg).
> 
> Yes, this is intentional, see:
> 
> https://marc.info/?l=xen-devel=144482080812353
> 

Note that I reverted that change yesterday. 4.7 will behave as before.

Wei.
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7 and blkback changes - domU respawning on_crash

2016-06-09 Thread Roger Pau Monné 
On Wed, Jun 08, 2016 at 10:35:22PM +, Marcin Cieslak wrote:
> On Wed, 8 Jun 2016, Marcin Cieslak wrote:
> 
> > On Fri, 3 Jun 2016, Roger Pau Monné wrote:
> > 
> > > Hello,
> > > 
> > > First of all, this message is only relevant to those that use FreeBSD as 
> > > Dom0 (host), not as a DomU (guest), so don't panic.
> > > 
> > > I've imported the latest Xen version (4.7-rc4) into the ports tree, it's 
> > > still not the final version, but it's quite close, so we better start 
> > > testing it to make sure it works fine with FreeBSD.
> 
> One issue maybe unrelated to FreeBSD:
> 
> This domain:
> 
> builder = "hvm"
> memory = 4096
> vcpus = 2
> name = "Windows2016"
> disk = [
> '/dev/zvol/zroot/windows0,raw,hda,w',
> '/dev/zvol/zroot/vs2013,raw,hdb,w',
> #'/root/win/install.iso,raw,hdc:cdrom,r'
> ]
> boot = "c" # Boot to hard disk image
> vnc = 2
> #vnclisten = "0.0.0.0"
> usbdevice = 'tablet'
> on_poweroff = 'destroy'
> on_reboot = 'restart'
> on_crash = 'restart'
> acpi = 1
> bios = 'ovmf'
> vif = [ 'bridge=bridge0,mac=00:16:3e:5d:0d:48' ]
> videoram=16
> vga = "stdvga"
> 
> crashes because I didn't have ovmf image:
> 
> (d203) HVM Loader
> (d203) Detected Xen v4.7.0-rc
> (d203) Xenbus rings @0xfeffc000, event channel 1
> (d203) Unknown BIOS ovmf, no ROM image found
> (d203) *** HVMLoader bug at hvmloader.c:229
> (d203) *** HVMLoader crashed.
> 
> But I seem unable to kill it with "xl destroy" - it keeps
> respawning again:
> 
> Windows2016211  4079 1 --p---   
> 0.0
> Windows2016213  4096 1 --psc-   
> 0.0
> (disappears)
> Windows2016221  4096 1 --psc-   
> 0.0
> (null) 221   147 1 --psc-   
> 0.0
> ...
> ...
> 
> I have finally managed to snatch it by issuing this a few times, after
> changing the "on_crash" to 'destroy':
> 
> # xl config-update Windows2016 xen/windows-run.cfg
> WARNING: xl now has better capability to manage domain configuration, avoid 
> using this command when possible
> setting dom243 configuration

The problem is that the domain crashed so early on boot that you weren't 
able to destroy it, and kept rebooting due to the "on_crash = 'restart'" 
option. IIRC I've also used the following hacky rune in order to terminate 
this kind of domains: "while [ 1 ]; do xl destroy ; done", but your 
solution seems better.

Roger.
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7: no blkback

2016-06-08 Thread Marcin Cieslak 
On Fri, 3 Jun 2016, Roger Pau Monné wrote:

> One of the more relevant changes in 4.7 regarding FreeBSD is the support for 
> block hotplug scripts. This means that we now have the option to use 
> backends different than simple block or regular files, provided that someone 
> writes the proper hotplug scripts to attach them (I've heard there are some 
> iSCSI hotplug scripts around). This however requires changes in blkback, so 
> if you plan to use the Xen 4.7 port, please make sure that you are running a 
> kernel that contains revision r301269 (or any later version). The same also 

I am running it with r301685 and the HVM guests have some trouble with
block devices.

SeaBIOS does not find /dev/zvol/zroot/freebsd1,raw,xvda,w to boot FreeBSD
from, after chaging to "hda" I get up to the kernel mountroot prompt
(Xen block devices seem to be detected in dmesg).

What used to be Windows 2016 domU with /dev/zvol/zroot/windows0,raw,hda,w
ends up in the Tianocore UEFI shell. Block devices seem to be available,
I can even list the fs0: partition, but no booting further possible.

Marcin

# more freebsd.cfg 
builder = "hvm"
name = "FreeBSD"
disk = [
'/dev/zvol/zroot/freebsd1,raw,xvda,w',
'/dev/zvol/zroot/freebsd2,raw,xvdb,w'
]
boot = "c"
#usbdevice = 'tablet'
#nographics = 1
serial = [ "file:/tmp/boot.log" ]
vnc = 1
#vnclisten = '0.0.0.0'
vif = ['bridge=bridge0,mac=00:02:04:08:fd:f0']
memory=2048
vcpus=1
vga = "cirrus"
videoram = 16

# more windows-run.cfg 
builder = "hvm"
memory = 4096
vcpus = 2
name = "Windows2016"
disk = [
'/dev/zvol/zroot/windows0,raw,hda,w',
'/dev/zvol/zroot/vs2013,raw,hdb,w',
#'/root/win/install.iso,raw,hdc:cdrom,r'
]
boot = "c" # Boot to hard disk image
vnc = 2
#vnclisten = "0.0.0.0"
usbdevice = 'tablet'
on_poweroff = 'destroy'
on_reboot = 'restart'
#on_crash = 'restart'
on_crash = 'destroy'
acpi = 1
bios = 'ovmf'
vif = [ 'bridge=bridge0,mac=00:16:3e:5d:0d:48' ]
videoram=16
vga = "stdvga"
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Re: HEADS UP: Imported Xen 4.7 and blkback changes - domU respawning on_crash

2016-06-08 Thread Marcin Cieslak 
On Wed, 8 Jun 2016, Marcin Cieslak wrote:

> On Fri, 3 Jun 2016, Roger Pau Monné wrote:
> 
> > Hello,
> > 
> > First of all, this message is only relevant to those that use FreeBSD as 
> > Dom0 (host), not as a DomU (guest), so don't panic.
> > 
> > I've imported the latest Xen version (4.7-rc4) into the ports tree, it's 
> > still not the final version, but it's quite close, so we better start 
> > testing it to make sure it works fine with FreeBSD.

One issue maybe unrelated to FreeBSD:

This domain:

builder = "hvm"
memory = 4096
vcpus = 2
name = "Windows2016"
disk = [
'/dev/zvol/zroot/windows0,raw,hda,w',
'/dev/zvol/zroot/vs2013,raw,hdb,w',
#'/root/win/install.iso,raw,hdc:cdrom,r'
]
boot = "c" # Boot to hard disk image
vnc = 2
#vnclisten = "0.0.0.0"
usbdevice = 'tablet'
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
acpi = 1
bios = 'ovmf'
vif = [ 'bridge=bridge0,mac=00:16:3e:5d:0d:48' ]
videoram=16
vga = "stdvga"

crashes because I didn't have ovmf image:

(d203) HVM Loader
(d203) Detected Xen v4.7.0-rc
(d203) Xenbus rings @0xfeffc000, event channel 1
(d203) Unknown BIOS ovmf, no ROM image found
(d203) *** HVMLoader bug at hvmloader.c:229
(d203) *** HVMLoader crashed.

But I seem unable to kill it with "xl destroy" - it keeps
respawning again:

Windows2016211  4079 1 --p---   0.0
Windows2016213  4096 1 --psc-   0.0
(disappears)
Windows2016221  4096 1 --psc-   0.0
(null) 221   147 1 --psc-   0.0
...
...

I have finally managed to snatch it by issuing this a few times, after
changing the "on_crash" to 'destroy':

# xl config-update Windows2016 xen/windows-run.cfg
WARNING: xl now has better capability to manage domain configuration, avoid 
using this command when possible
setting dom243 configuration


Marcin
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"