http://blog.gmane.org/gmane.os.netbsd.ports.xen hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7958 <pre> You will have to setup a serial console in order to obtain a log, without that it is impossible to say what's going on. </pre> Roger Pau Monné 2013-05-23T14:48:22 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7956 <pre> Many thanks for this. Just updated an 8 guest xn box from 4.1 to 4.2, and may have picked up some possible xentools42 issues. In the installed package /usr/pkg/bin/pygrub was a symlink to itself. Manually copied work/xen-4.2.2/tools/pygrub/build/scripts-2.7/pygrub to /usr/pkg/bin /var/run/xen/bootloader.1.d was not present - created by hand to continue etc/xen/oxenstored.conf was not present - I set PKG_SYSCONFBASE?=/etc for some packages so that would be related. On starting the guests (CentOS 6) they seemed to fire up ok but then exited. The console had: XENBUS: Waiting for devices to initialise: 295s...290s...285s...280s...275s...270s...265s...260s...255s...250s...245s...240s...235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s... XENBUS: Timeout connecting to device: device/vbd/51712 (local state 3, remote state 2) Loading dm-mod.ko module device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.11.6-ioctl (2011-02-18) initialised: dm-devel&lt; at &gt;redhat.com Loading dm-log.ko module Loading dm-mirror.ko module Loading dm-zero.ko module Loading dm-snapshot.ko module Loading dm-mem-cache.ko module Loading dm-region_hash.ko module Loading dm-message.ko module Loading dm-raid45.ko module device-mapper: dm-raid45: initialized v0.2594l Scanning and configuring dmraid supported devices Scanning logical volumes [then exited] cat xl-jira.log.2 Waiting for domain jira (domid 20) to die [pid 26919] Domain 20 has shut down, reason code 0 0x0 Action for shutdown reason code 0 is destroy Domain 20 needs to be cleaned up: destroying the domain Done. Exiting now the .cfg for that VM: name = "jira" memory = "1536" disk = [ 'file:/opt/xen/img/jira.img,0xca00,w', ] vif = [ 'mac=02:00:00:00:01:03, bridge=bridge0', ] bootloader = "/usr/pkg/bin/pygrub" vcpus = 3 Rolling back to 41 for now :) </pre> David Brownlee 2013-05-21T08:28:14 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7955 <pre>On Wed, May 15, 2013 at 10:26 AM, Christoph Egger &lt;Christoph_Egger&lt; at &gt;gmx.de&gt; wrote: I agree 100% with this! I've tried myself to compile it but I see some patches need to be done, I'll be happy to help testing! </pre> Miguel Clara 2013-05-16T01:51:05 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7954 <pre> I prefer to test Xen 4.3 and get patches upstream rather into pkgsrc before Xen 4.3 release is out! Christoph </pre> Christoph Egger 2013-05-15T09:26:58 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7953 <pre>Le 15/05/2013 09:18, jnemeth&lt; at &gt;victoria.tc.ca a écrit : Thanks for your work! That depends on the portability efforts of your patches from 4.2 to 4.3 (that remark will not help you much, I know). Regarding 4.3, there are a few things that will definitely impact NetBSD in terms of integration: - PCI passthru is closer to the upstreamed QEMU (and also KVM); the upstreaming will likely require patches to adapt to this change in xpci(4) and pciback(4) (hence: more patches); - CD insertion/ejection through xl (unknown impact on PV guests); - the cpuidle feature does not require ACPI magic from dom0 anymore, so those that use Xen on a laptop (my case for example) will have an easier time with heat and battery consumption. No patch required, only testing (which I can easily do: booting it on my laptop). Although 4.3 provides notable improvements, I would not rush into it instead of 4.2. The modifications affect other areas than those you had to patch in 4.2, and getting 4.2 working decently first (especially xl...) is a better choice IMHO. Cheers, </pre> Jean-Yves Migeon 2013-05-15T08:30:53 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7952 <pre> I've just committed sysutils/xenkernel42 and sysutils/xentools42. They have had fairly extensive testing, but they are just initial commits. I've added them so that people can test them, break them, improve them, etc. Note that xm/xend is deprecated but they do still work. xl is working in this version. But, I've only tested it with file backed vbds. I haven't tested it with LVM or raw partitions. Major things that don't work yet are HVM and grant tables. The issue with HVM is that Qemu wasn't compiling, and I just commented it out in order to move forward. The issue with grant tables is that it appears that the interface has changed and I haven't fully adapted the code. So, have at it. Let me know what breaks. Patches would be greatly appreciated (or just commit if you have cvs access). Otherwise, I need enough details on what breaks in order to duplicate/fix the problem. One thing to note is that Xen 4.3.0rc1 was released a week ago. This raises the question of whether to spend a lot of time working on improving the Xen 4.2 packages, or switch to starting work on the Xen 4.3 packages? Any thoughts on this question? </pre> John Nemeth 2013-05-15T07:18:34 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7951 <pre> AFAIK it should work without problems. </pre> Roger Pau Monné 2013-05-10T08:20:56 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7950 <pre>Understood and I didn't explain it well. Instead of having a line in /etc/rc.conf that says xend=YES, what you can also do is to have file named xencommons under /etc/rc.conf.d that contains the line xend=YES. See /etc/rc.subr:load_rc_config() for why this works. Granted that you don't want xend to turn be turned on, but if you do, you can have another file named xend under /etc/rc.conf.d that contains the line xend=YES. I find this a bit gnarly and I'm not sure why it was done that way, but maybe it was to reduce surprises with missing a new setting when moving from xen 3.3, who knows. Alternatively, if you want the name of the knob to be xencommons, you can change the xencommons rc.d script so that rcvar=xencommons or rcvar=$name. Onto the issue of getting differing ${DIR} during boot vs when invoked manually (e.g. /etc/rc.d/xencommons start), that's because /etc/rc basically just sources each file in /etc/rc.d during boot, in which case $0 in xencommons is actually /etc/rc and so $(dirname $0) is /etc. So, that's a bug in the way xencommons is trying to include xen-hotplugpath.sh. In the meantime your workaround obviously is fine. I'm pleasantly surprised that xen 4.2 seems to work without too much fuss on netbsd even when compiled from source. Does support for file based/vnd based disk work? Toby </pre> Toby Karyadi 2013-05-10T02:15:30 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7949 <pre>Hello, So after realizing that libgpod does not support 7th gen iPods, I'm looking for alternative ways to upload some music there. I have a NetBSD dom0 at home. Wondering if it would be possible to xm block-attach the iPod, make it visible in a Windows VM and use iTunes from there? Anyone tried a similar scheme? Regards, Hugo </pre> Hugo Silva 2013-05-09T17:13:13 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7948 <pre>Hi, just wanted to report that I bumped into this while creating a DomU (debian) libxl: error: libxl_bootloader.c:364:libxl__bootloader_run: failed to create bootloader dir /var/run/xen/bootloader.3.d: No such file or directory libxl: error: libxl_create.c:919:domcreate_rebuild_done: cannot (re-)build domain: -3 Dom0 is netbsd 6.0.1, Xen 4.2 compile from source! This is a mirror problem has the dir (/var/run/xen) can be manually created, but I guess this should be created while installing (or not ) PS: While testing I also found that xencommons requires xend and probably shouldn't. Thanks for keeping improving Xen support on netbsd! Mike </pre> Miguel Clara 2013-05-09T09:25:48 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7947 <pre>This is xen 4.2... xend is not needed unless I wanted to use xm... I commented that line btw! I solved it the lazy way for now with a symlink so both locations work, but I would like to understand what is wrong. Thanks for the feedback. Sent from my BlackBerry 10 smartphone. </pre> Miguel Clara 2013-05-09T09:14:06 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7946 <pre>Hmm, yes, you'd think that the name of the knob is xencommons, but instead it's xend. So it's supposed to be: xend=YES. See if that improves anything. If you look at the xencommons rc script, it wants the rcvar to be 'xend'. I don't know if that will improve anything related to the xen-hotplugpath.sh path. Toby On 5/8/13 8:35 PM, Miguel Clara wrote: </pre> Toby Karyadi 2013-05-09T01:53:02 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7945 <pre>I noticed that after settings xencommons=YES on rc.conf the daemon wasn't starting! I looked at /var/run/rc.log and found this: running /etc/rc.d/xencommons] .: Can't open /etc/xen-hotplugpath.sh /etc/rc.d/xencommons exited with code 2 [running /etc/rc.d/xend] .: Can't open /etc/xen-hotplugpath.sh /etc/rc.d/xend exited with code 2 [running /etc/rc.d/xen-watchdog] .: Can't open /etc/xen-hotplugpath.sh /etc/rc.d/xen-watchdog exited with code 2 [running /etc/rc.d/xen-hotplugpath.sh] I had it on /etc/rc.d .... because xencommons has this lines: DIR=$(dirname "$0") . "${DIR}/xen-hotplugpath.sh" In any case just for testing I move xen-hotplugpath.sh to /etc/xen... and run /etc/rc.d/xencommons start and now I get: # /etc/rc.d/xencommons start .: Can't open /etc/rc.d/xen-hotplugpath.sh What could be the reason for "dirname" to get a different result while booting and after I'm logged in? NOTE: Running netbsd 6.0.1, xen 4.2 compiled from source </pre> Miguel Clara 2013-05-09T00:35:04 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7944 <pre>Am 29.04.2013 16:41, schrieb Sam Fourman Jr.: I finally gave up. PCI pass through didn't work. Back in January, I tried to quick fix libxl_device_pci_reset(). Afterwards, I stepped into errors behind that procedure (mainly, because xl expected Linux style /sysfs etc.). So I wasn't convinced that Xen 4.1 and NBSD 6.0 works properly in all cases. Furthermore I own a Gigabyte 970A-UD3 which suffers from [0]. So I'm not sure, if the problems I encountered a board specific or not. Regards, Marcus [0] http://lists.xen.org/archives/html/xen-devel/2013-03/msg01018.html </pre> Marcus Osdoba 2013-04-29T20:44:58 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7943 <pre> vga passthrough, probably not. AMD-Vi is probably mostly a hypervisor things, maybe no specific support is needed on the NetBSD side. </pre> Manuel Bouyer 2013-04-29T20:25:11 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7942 <pre> Thanks! P </pre> Patrick Welche 2013-04-09T15:48:40 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7941 <pre> Yes, you need to tell xen to use the serial console. With console=com0, NetBSD uses Xen hypercalls to talk to the console, and the console it under the hypervisor's control. So this would be: menu=Boot Xen 4.1 debug dom0 (com0):load /netbsd-XEN3_DOM0 console=com0;multiboot /xen-debug.gz dom0_mem=512M console=com1 com1=9600,8n1 (NetBSD counts from 0, xen from 1 for com). </pre> Manuel Bouyer 2013-04-07T20:55:15 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7940 <pre>On a particular -current/amd64 box, NetBSD + serial console is fine, XEN_DOM0 on pc console is fine. However with the following incantation nothing appears on the end of the serial line, nor on the screen: menu=Boot Xen 4.1 debug dom0 (com0):load /netbsd-XEN3_DOM0 console=com0;multiboot /xen-debug.gz dom0_mem=512M I can ssh in and all is OK, but I can't see console output... BIOS and NetBSD bootblocks set baud rate to 115200. I tried 115200 and 9600 in the hope of seeing something. Is the incantation wrong? Cheers, Patrick </pre> Patrick Welche 2013-04-07T12:45:03 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7939 <pre> At its simplest, testing NetBSD as a Xen guest could consist of installing anita &lt;http://www.gson.org/netbsd/anita/download/anita-1.29.tar.gz&gt; on the dom0 and running anita --vmm xl test http://ftp.netbsd.org/pub/NetBSD/NetBSD-5.0.2/i386/ The dom0 does not have to be running NetBSD; Linux will work just as well. </pre> Andreas Gustafsson 2013-03-25T13:14:50 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7938 <pre> Cool. </pre> matthew sporleder 2013-03-25T11:44:37 http://permalink.gmane.org/gmane.os.netbsd.ports.xen/7937 <pre> Hi, http://wiki.xen.org/wiki/GSoC_2013#Testing_NetBSD Christoph </pre> Christoph Egger 2013-03-25T11:11:49 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.ports.xen