Xen users - May 2013 - Xen 4.2 + XP x64 + PVGPL 2K3 x64 = BSOD (UNMOUNTABLE_BOOT_VOLUME)

The subject says it all, really.

I couldn''t find any XP x64 specific drivers, but in all other cases 2K3
x64 drivers have worked for me on XP x64, so since the kernels and 
driver models are the same, I am guessing this should work.

Thankfully I took a snapshot of the block device before installing the 
drivers.

Is there a better driver to use on XP x64?

The HVM disk performance is really quite attrocious. From dom0, I get 
about 60MB/s on unbuffered reads with dd iflag=direct and hdparm -t. 
 From domU I get 5MB/s and qemu-dm hits 100% CPU usage.

Is there a way to make this work / establish why it doesn''t work?

Gordan

On May 19, 2013, at 5:10 AM, Gordan Bobic <gordan@bobich.net> wrote:
> The subject says it all, really.
>
> I couldn''t find any XP x64 specific drivers, but in all other
cases 2K3 x64 drivers have worked for me on XP x64, so since the kernels and
driver models are the same, I am guessing this should work.
>
> Thankfully I took a snapshot of the block device before installing the
drivers.
>
> Is there a better driver to use on XP x64?
>
> The HVM disk performance is really quite attrocious. From dom0, I get about
60MB/s on unbuffered reads with dd iflag=direct and hdparm -t. From domU I get
5MB/s and qemu-dm hits 100% CPU usage.
>
> Is there a way to make this work
Always!  I''m just not sure how :P
> establish why it doesn''t work?
If you could get the system booted from a completely different storage
device, and then try to get GPLPV working on a volume that''s not the
boot volume, that might be a good place to start.  Personally, due to
either my brand of weirdness or perhaps tunnel vision, I would boot
from an iSCSI volume and then attempt to interact with the "local"
disks that way.

Alternatively, the only other method is probably to hook up the kernel
debugger and interrogate things from there.  :P

Cheers,
Andrew
> Gordan
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users

On 05/19/2013 06:14 PM, Andrew Bobulsky wrote:
> On May 19, 2013, at 5:10 AM, Gordan Bobic <gordan@bobich.net> wrote:
>
>> The subject says it all, really.
>>
>> I couldn''t find any XP x64 specific drivers, but in all other
cases 2K3 x64 drivers have worked for me on XP x64, so since the kernels and
driver models are the same, I am guessing this should work.
>>
>> Thankfully I took a snapshot of the block device before installing the
drivers.
>>
>> Is there a better driver to use on XP x64?
>>
>> The HVM disk performance is really quite attrocious. From dom0, I get
about 60MB/s on unbuffered reads with dd iflag=direct and hdparm -t. From domU I
get 5MB/s and qemu-dm hits 100% CPU usage.
>>
>> Is there a way to make this work
>
> Always!  I''m just not sure how :P
>
>> establish why it doesn''t work?
>
> If you could get the system booted from a completely different storage
> device, and then try to get GPLPV working on a volume that''s not
the
> boot volume, that might be a good place to start.  Personally, due to
> either my brand of weirdness or perhaps tunnel vision, I would boot
> from an iSCSI volume and then attempt to interact with the
"local"
> disks that way.
Funny you should mention iSCSI. My setup is an iSCSI volume exposed to 
the domU "raw" as a physical IDE disk. But domU seems to be alergic to
it. If I leave the disk spec in the domU config as hda, it BSODs with 
the mentioned error. If I change it in the config to xvda, the domU 
starts to burn through 100% of CPU on all cores given to it and never 
finishes booting.
> Alternatively, the only other method is probably to hook up the kernel
> debugger and interrogate things from there.  :P
Nothing ever "just works", does it...

Gordan

On May 19, 2013, at 10:18 AM, Gordan Bobic <gordan@bobich.net> wrote:
> On 05/19/2013 06:14 PM, Andrew Bobulsky wrote:
>> On May 19, 2013, at 5:10 AM, Gordan Bobic <gordan@bobich.net>
wrote:
>>
>>> The subject says it all, really.
>>>
>>> I couldn''t find any XP x64 specific drivers, but in all
other cases 2K3 x64 drivers have worked for me on XP x64, so since the kernels
and driver models are the same, I am guessing this should work.
>>>
>>> Thankfully I took a snapshot of the block device before installing
the drivers.
>>>
>>> Is there a better driver to use on XP x64?
>>>
>>> The HVM disk performance is really quite attrocious. From dom0, I
get about 60MB/s on unbuffered reads with dd iflag=direct and hdparm -t. From
domU I get 5MB/s and qemu-dm hits 100% CPU usage.
>>>
>>> Is there a way to make this work
>>
>> Always!  I''m just not sure how :P
>>
>>> establish why it doesn''t work?
>>
>> If you could get the system booted from a completely different storage
>> device, and then try to get GPLPV working on a volume that''s
not the
>> boot volume, that might be a good place to start.  Personally, due to
>> either my brand of weirdness or perhaps tunnel vision, I would boot
>> from an iSCSI volume and then attempt to interact with the
"local"
>> disks that way.
>
> Funny you should mention iSCSI. My setup is an iSCSI volume exposed to the
domU "raw" as a physical IDE disk. But domU seems to be alergic to it.
If I leave the disk spec in the domU config as hda, it BSODs with the mentioned
error. If I change it in the config to xvda, the domU starts to burn through
100% of CPU on all cores given to it and never finishes booting.
Ooooo..... Well, you can try it if you like.  Download the Microsoft
iSCSI boot-capable initiator, install it, then download and install
sanbootconf from the iPXE web site.

Once you''re done, reboot the domain and boot from the built-in iPXE.
Use Ctrl-B to enter the command line and run the following:

dhcp net0
sanboot iscsi:your.iscsi.server::::name.of.target

That''s assuming you''re not using chap auth or something, and
that your
LUN is also LUN 0 on the target.  I can dig up the doc if you need
help on that, though :)
>> Alternatively, the only other method is probably to hook up the kernel
>> debugger and interrogate things from there.  :P
>
> Nothing ever "just works", does it...
>
> Gordan
Nope!  I''ve got a pile of dead MacBooks to prove it!  Muahahahah ;)

-Andrew

> 
> The subject says it all, really.
> 
> I couldn''t find any XP x64 specific drivers, but in all other
cases 2K3
> x64 drivers have worked for me on XP x64, so since the kernels and
> driver models are the same, I am guessing this should work.
> 
> Thankfully I took a snapshot of the block device before installing the
> drivers.
> 
> Is there a better driver to use on XP x64?
> 
> The HVM disk performance is really quite attrocious. From dom0, I get
> about 60MB/s on unbuffered reads with dd iflag=direct and hdparm -t.
>  From domU I get 5MB/s and qemu-dm hits 100% CPU usage.
> 
> Is there a way to make this work / establish why it doesn''t work?
> 
The 2003_x64 drivers are the right ones to use. What version GPLPV are you
using?

James

On Sun, 19 May 2013 10:42:06 -0700, Andrew Bobulsky <rulerof@gmail.com> 
 wrote:
> On May 19, 2013, at 10:18 AM, Gordan Bobic <gordan@bobich.net> wrote:
>
>> On 05/19/2013 06:14 PM, Andrew Bobulsky wrote:
>>> On May 19, 2013, at 5:10 AM, Gordan Bobic <gordan@bobich.net>
>>> wrote:
>>>
>>>> The subject says it all, really.
>>>>
>>>> I couldn''t find any XP x64 specific drivers, but in
all other
>>>> cases
>>>> 2K3 x64 drivers have worked for me on XP x64, so since the
kernels
>>>> and driver models are the same, I am guessing this should work.
>>>>
>>>> Thankfully I took a snapshot of the block device before
installing
>>>> the drivers.
>>>>
>>>> Is there a better driver to use on XP x64?
>>>>
>>>> The HVM disk performance is really quite attrocious. From dom0,
>>>> I get about 60MB/s on unbuffered reads with dd iflag=direct and
>>>> hdparm -t. From domU I get 5MB/s and qemu-dm hits 100% CPU
usage.
>>>>
>>>> Is there a way to make this work
>>>
>>> Always!  I''m just not sure how :P
>>>
>>>> establish why it doesn''t work?
>>>
>>> If you could get the system booted from a completely different 
>>> storage
>>> device, and then try to get GPLPV working on a volume
that''s not
>>> the
>>> boot volume, that might be a good place to start.  Personally, due 
>>> to
>>> either my brand of weirdness or perhaps tunnel vision, I would boot
>>> from an iSCSI volume and then attempt to interact with the
"local"
>>> disks that way.
>>
>> Funny you should mention iSCSI. My setup is an iSCSI volume exposed
>> to the domU "raw" as a physical IDE disk. But domU seems to
be
>> alergic to it. If I leave the disk spec in the domU config as hda,
>> it BSODs with the mentioned error. If I change it in the config to
>> xvda, the domU starts to burn through 100% of CPU on all cores given
>> to it and never finishes booting.
>
> Ooooo..... Well, you can try it if you like.  Download the Microsoft
> iSCSI boot-capable initiator, install it, then download and install
> sanbootconf from the iPXE web site.
>
> Once you''re done, reboot the domain and boot from the built-in
iPXE.
> Use Ctrl-B to enter the command line and run the following:
>
> dhcp net0
> sanboot iscsi:your.iscsi.server::::name.of.target
>
> That''s assuming you''re not using chap auth or something,
and that
> your
> LUN is also LUN 0 on the target.  I can dig up the doc if you need
> help on that, though :)
 I have considered PXE booting the domU, but my concern is that I can
 only do that via the emulated NIC. If qemu-dm tops out at 5MB/s on
 emulated devices, this is presumably going to be just as bad.

 Is there a way to PXE boot the domU via the physical PCI passthrough
 NIC?

 Gordan

Good day, Gordan,
On Mon, May 20, 2013 at 4:36 AM, Gordan Bobic <gordan@bobich.net> wrote:
> On Sun, 19 May 2013 10:42:06 -0700, Andrew Bobulsky
<rulerof@gmail.com>
> wrote:
>
>> On May 19, 2013, at 10:18 AM, Gordan Bobic <gordan@bobich.net>
wrote:
>>
>>  On 05/19/2013 06:14 PM, Andrew Bobulsky wrote:
>>>
>>>> On May 19, 2013, at 5:10 AM, Gordan Bobic
<gordan@bobich.net> wrote:
>>>>
>>>>  The subject says it all, really.
>>>>>
>>>>> I couldn''t find any XP x64 specific drivers, but
in all other cases
>>>>> 2K3 x64 drivers have worked for me on XP x64, so since the
kernels
>>>>> and driver models are the same, I am guessing this should
work.
>>>>>
>>>>> Thankfully I took a snapshot of the block device before
installing the
>>>>> drivers.
>>>>>
>>>>> Is there a better driver to use on XP x64?
>>>>>
>>>>> The HVM disk performance is really quite attrocious. From
dom0,
>>>>> I get about 60MB/s on unbuffered reads with dd iflag=direct
and
>>>>> hdparm -t. From domU I get 5MB/s and qemu-dm hits 100% CPU
usage.
>>>>>
>>>>> Is there a way to make this work
>>>>>
>>>>
>>>> Always!  I''m just not sure how :P
>>>>
>>>>  establish why it doesn''t work?
>>>>>
>>>>
>>>> If you could get the system booted from a completely different
storage
>>>> device, and then try to get GPLPV working on a volume
that''s not the
>>>> boot volume, that might be a good place to start.  Personally,
due to
>>>> either my brand of weirdness or perhaps tunnel vision, I would
boot
>>>> from an iSCSI volume and then attempt to interact with the
"local"
>>>> disks that way.
>>>>
>>>
>>> Funny you should mention iSCSI. My setup is an iSCSI volume exposed
>>> to the domU "raw" as a physical IDE disk. But domU seems
to be
>>> alergic to it. If I leave the disk spec in the domU config as hda,
>>> it BSODs with the mentioned error. If I change it in the config to
>>> xvda, the domU starts to burn through 100% of CPU on all cores
given
>>> to it and never finishes booting.
>>>
>>
>> Ooooo..... Well, you can try it if you like.  Download the Microsoft
>> iSCSI boot-capable initiator, install it, then download and install
>> sanbootconf from the iPXE web site.
>>
>> Once you''re done, reboot the domain and boot from the built-in
iPXE.
>> Use Ctrl-B to enter the command line and run the following:
>>
>> dhcp net0
>> sanboot iscsi:your.iscsi.server::::**name.of.target
>>
>> That''s assuming you''re not using chap auth or
something, and that your
>> LUN is also LUN 0 on the target.  I can dig up the doc if you need
>> help on that, though :)
>>
>
> I have considered PXE booting the domU, but my concern is that I can
> only do that via the emulated NIC. If qemu-dm tops out at 5MB/s on
> emulated devices, this is presumably going to be just as bad.
>
> Is there a way to PXE boot the domU via the physical PCI passthrough
> NIC?
>
> Gordan

If PCI passthrough works the way I think it works, then it just might.
Pre-OS interaction with PCI devices (a-la Primary/VGA Passthrough) requires
mapping memory such that an option ROM can interact with the device in the
same way it would when a system is first booted.  One of the great things
about iPXE is that, while it interacts with the BIOS via that tradition
option ROM interface, it scans the PCI bus itself, hunting for PNP devices
in much the same way that a Windows or Linux kernel would when it starts
up..... and since utilization of passed-through PCI devices works *extremely
well* in those circumstances, I wouldn''t be at all surprised if it does
work.

The build of iPXE that is included with Xen is... a little on the old
side.  All I really know about it is that my scripts don''t work
properly in
it---I actually chainload a custom iPXE build from Xen''s built-in copy,
and
then go from there.  If you happen to have iPXE deployed on your network,
give that a try.  Otherwise, download and boot the pre-built iPXE ISO
image[1] and use that instead, as it is designed to be highly
compatible. Just pop it into you DomU config file and see what happens?
(I''m super curious!)

Cheers,
Andrew

[1]: http://boot.ipxe.org/ipxe.iso

PS: As I think about it, the ability to have iPXE work directly on a
passed-through NIC I speculate that, especially with the coming disruption
to the entire logistics of VM networking represented by SR/MR-IOV would
make this a very useful note for someone, I''m sure :)


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

Hi Everybody,

I have a HOST (*/Server Fisico/*) connected to internet. It have 2 
network cards, the first one (*/eth0/*) connected to the router, another 
(/*eth1*/) is connected to LAN.
/*eth1*/ is bridged to virtual machines network, and one of them 
(*/virtual1/*) have an HTTP Server. Everything is running correctly.


Escenario
I have IPTABLES Firewall running on the HOST with DNAT forwarding HTTP 
traffic to /*Virtual1*/. I have IPTABLES Rules in HOST, for block some 
IPs that give me problems, but these rules not protect to /*Virtual1*/. 
All HTTP traffic is forwarded to /*Virtual1*/, even the source IP is 
blocked for IPTABLES rules.

I had an attack, and I couldn''t block the HTTP traffic about 
/*Virtual1*/, the IPTABLES rules not affect it.

What can I do for give security to Virtual machines?

Thanks a lot
Alberto





_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

On Tue, May 21, 2013 at 5:51 AM, Alberto <alberto@bersol.info> wrote:
>  Hi Everybody,
>
> I have a HOST (*Server Fisico*) connected to internet. It have 2 network
> cards, the first one (*eth0*) connected to the router, another (*eth1*)
> is connected to LAN.
> *eth1* is bridged to virtual machines network, and one of them (*virtual1*)
> have an HTTP Server. Everything is running correctly.
>
>
> [image: Escenario]
> I have IPTABLES Firewall running on the HOST with DNAT forwarding HTTP
> traffic to *Virtual1*. I have IPTABLES Rules in HOST, for block some IPs
> that give me problems, but these rules not protect to *Virtual1*. All
> HTTP traffic is forwarded to *Virtual1*, even the source IP is blocked
> for IPTABLES rules.
>
If I understand your problem correctly...

Did you do the following?

echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables

To check:

cat /proc/sys/net/bridge/bridge-nf-call-iptables
cat /proc/sys/net/bridge/bridge-nf-call-ip6tables

More reading at http://ebtables.sourceforge.net/misc/brnf-faq.html

Hope this helps!

Thanks.

Kindest regards,
Giam Teck Choon



>
> I had an attack, and I couldn''t block the HTTP traffic about
*Virtual1*,
> the IPTABLES rules not affect it.
>
> What can I do for give security to Virtual machines?
>
> Thanks a lot
> Alberto
>
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

Hello.

El 20/05/13 16:51, Alberto escribió:
> I have a HOST (*/Server Fisico/*) connected to internet. It have 2
> network cards, the first one (*/eth0/*) connected to the router, another
> (/*eth1*/) is connected to LAN.
> /*eth1*/ is bridged to virtual machines network, and one of them
> (*/virtual1/*) have an HTTP Server. Everything is running correctly.
I will assume that your HOST server is running running Xen Dom0.
Probably, it is also acting as a router between 192.168.1.X and 
192.168.2.X, that makes DNAT and firewall to run within the same Dom0.

> I have IPTABLES Firewall running on the HOST with DNAT forwarding HTTP
> traffic to /*Virtual1*/. I have IPTABLES Rules in HOST, for block some
> IPs that give me problems, but these rules not protect to /*Virtual1*/.
> All HTTP traffic is forwarded to /*Virtual1*/, even the source IP is
> blocked for IPTABLES rules.
Vrtual1 is probably a DomU running on the same HOST.

What happens here, is that there might be a iptables rule, matching the 
unwelcome incoming connection, that is evaluated before the rules that 
intend to block that connection. Once it is matched, the decision ACCEPT 
is made and no other rule is evaluated. To make sure, a careful 
inspection of "iptables -L -v" is needed.

Please note that Xen Dom0''s firewall need to be quite permissive in 
order to make network communication to work. A fine configuration is 
possible, but fairly tricky to set up, and even more tricky to maintain.
> I had an attack, and I couldn''t block the HTTP traffic about
> /*Virtual1*/, the IPTABLES rules not affect it.
>
> What can I do for give security to Virtual machines?
The first recommendation is to give security to your Dom0 machine, do 
not expose it directly to your DMZ network. Your advantage here is that 
you have 2 network cards, so you can make a good separation. Second, 
avoid using the dom0 as router/firewall, Xen''s own iptables rules make 
things very confusing, it''s easer to leave Xen''s to Xen and do
the
firewalling on a dedicated VM, even within the same physical box.

I would suggest to reconsider the network topology.
1. Let''s say your "Servidor Fisico" had a bridge xenbr0
containing eth0,
and xenbr1 containing eth1. Make it not to have any IP on xenbr0 
(exposed), only on xenbr1 (internal).
2. Set up a virtual machine to act as router, make it have one interface 
within xenbr0 and another in xenbr1.
3. Make this virtual machine to route and NAT traffic between Internet 
and internal network, the same machine may act as DHCP server and DNS 
for your internal network. Your Virtual1 would be treated just as 
another host in your internal network.

This is a fairly simple but yet flexible setup, it will allow you keep 
things clear and separated one from another.

Greeting.


-- 
Alexandre Kouznetsov

On 05/20/2013 11:51 PM, Alberto wrote:
> What can I do for give security to Virtual machines?
>
> Thanks a lot
> Alberto
Hi Alberto,
once doing the SNAT/DNAT you can filter the connections in FORWARD table.

Just did some quick search on the net and find this nice iptables tutorial:
http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES
read the "Chapter 6. Traversing of tables and chains" section General 
with nice picture of all chains and their order.
Wish you nice reading and successful learning of iptables. ;-)

Best regards,
-- 
Peter Viskup


_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users

On 05/19/2013 11:56 PM, James Harper wrote:
>>
>> The subject says it all, really.
>>
>> I couldn''t find any XP x64 specific drivers, but in all other
cases 2K3
>> x64 drivers have worked for me on XP x64, so since the kernels and
>> driver models are the same, I am guessing this should work.
>>
>> Thankfully I took a snapshot of the block device before installing the
>> drivers.
>>
>> Is there a better driver to use on XP x64?
>>
>> The HVM disk performance is really quite attrocious. From dom0, I get
>> about 60MB/s on unbuffered reads with dd iflag=direct and hdparm -t.
>>   From domU I get 5MB/s and qemu-dm hits 100% CPU usage.
>>
>> Is there a way to make this work / establish why it doesn''t
work?
>>
>
> The 2003_x64 drivers are the right ones to use. What version GPLPV are you
using?
I tried using 2003x64 0.11.0.372.

Gordan