On Saturday, October 27, 2012 2:01:58 AM UTC+2, Marek Marczykowski wrote: On 26.10.2012 22:34, abb wrote:
>
>
> On Thursday, October 25, 2012 2:51:17 PM UTC+2, abb wrote:
>>
>> On Wednesday, October 24, 2012 11:18:51 PM UTC+2, Marek Marczykowski wrote:
>>>
>>> On 24.10.2012 23:07, abb wrote:
>>>
>>> (...)
>>>
>>>> These instructions work for me, but even for PV drivers one needs to
>>> fix
>>>> networking rules in netvm with something like
>>>> ---
>>>> fwcfg() {
>>>> vmip=$1
>>>>
>>>> iptables -A FORWARD -s $vmip -p udp -d 10.137.1.1 --dport 53 -j
>>> ACCEPT
>>>> iptables -A FORWARD -s $vmip -p udp -d 10.137.1.254 --dport 53 -j
>>> ACCEPT
>>>> iptables -A FORWARD -s $vmip -p icmp -j ACCEPT
>>>> iptables -A FORWARD -s $vmip -p tcp -d 10.137.255.254 --dport 8082
>>> -j
>>>> DROP
>>>> iptables -A FORWARD -s $vmip -j ACCEPT
>>>> }
>>>>
>>>> fwcfg 10.137.2.127
>>>> fwcfg 10.137.2.128
>>>> fwcfg 10.137.2.129
>>>> ---
>>>
>>> Indeed, VMs not managed by Qubes tools don't get firewall rules...
>>>
>>>> Disk performance is awful. On SSD it is 2MB/s, on mechanic disk it is
>>> some
>>>> 0.6MB/s and I can hear that the disk is being trashed really badly.
>>>
>>> This is much better with Qubes-managed HVMs, which uses stubdom to
>>> emulate
>>> devices.
>>>
>>>> I've managed to install Win7 (no networking) and NetBSD 6.0. Tried also
>>>> BT5R3 but this one trashes the disk particularly badly, never made it
>>>> through to the end of the install. NetBSD seems to run happily, but
>>> network
>>>> is not working, says "re0: watchdog timeout".
>>>
>>> Does NetBSD have network PV drivers?
>>
>>
>> According to their release info supposed to have it. And it detected the
>> interface re0.
>>
>>
>>> If so, perhaps have hardcoded dom0 as
>>> backend domain (which is sadly quite popular bug...). You can check 'xl
>>> dmesg'
>>> in dom0, if I guessed correctly, there will be some messages about gnttab
>>> or so.
>>>
>>
> Here is a relevant installation guide, I have not tried it yet:
> http://wiki.xen.org/wiki/How_to_install_a_NetBSD_PV_domU_on_a_Debian_Squeeze_host_%28Xen_4.0.1%29
>
> I did install from ISO and probably ended up without PV drivers, see
> attached screenshot.
Ok, looks to be emulated hardware, not PV. Anyway this still can be the
problem with unsupported backend != dom0. Don't remember details, but in case
of "non-qubes" HVM (without PV drivers) I've managed to get network in VM only
by routing through dom0...
Above instruction looks promising, I suggest you create standalone VM (based
on any template, the Linux inside will be overridden anyway), then place the
netbsd kernel in "kernels" subdir of VM (as "vmlinuz") and some placeholder
"initramfs". Then set kernel (via qvm-prefs) to "none".
During startup of such VM hit Ctrl-C while waiting for qrexec agent, then you
can access console via "sudo xl console <vmname>".
These instructions worked for me.
Create standalone VM with default template, replaced vmlinuz with netbsd-INSTALL_XEN3_DOMU kernel. During setup chosen to install on xbd1 hard disk. Could not figure out how to attach CD, 'qvm-start --cdrom=...' says VM does not support attaching disks. DHCP client in NetBSD didn't work during installation, so I had to manually configure the networking. The installation went fine, enabled SSHD during post-install configuration. Replaced the kernel with netbsd-XEN3_DOMU as the wiki says. It fails to boot automatically, need to explicitly specify xbd1a as root device when prompted. After bootstrap all works just fine, networking seems to work too (xennet0).
If you want to stick with HVM, you can use qvm-create --hvm, with new xen etc.
It really have many things fixed (eg non-dom0 backend support).
I tried 'qvm-create --hvm', got Windows7 installed just fine, networking works out of the box. Didn't try custom PV drivers yet.
--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab
|