Monday, May 05, 2008
Linux @ Home
My laptop at home dual-boots between openSUSE and WinXP. There are a few reasons why I don't boot the Linux side very often, some of them work related. And, what the heck, here are the two reasons.
1: Wireless driver problems
I have an intel 3945 WLAN card. It works just fine in linux, well supported. What throws it for a loop, however, are sleep and hibernate states. It can go one, two, four, maybe five cycles through sleep before it will require a reboot in order to find the home wireless again. If it doesn't lock the laptop up hard. Since my usage patterns are heavily dependent upon Sleep mode, this is a major, major disincentive to keep the Linux side booted.
I understand the 2.6.25 kernel is a lot better about this particular driver. Thus, I wait with eager anticipation the release of openSUSE 11.0. This driver is currently the ipw3945 driver, and will eventually turn into iwl3945 driver once it comes down the pipe. What little I've read about it suggests that the iwl driver is more stable through power states.
2: NetWare remote console
I use rconip for remote console to NetWare. Back when Novell first created the IP-based rconsole, they also released rconj along side ConsoleOne to provide it. As this was written in Java, it was mind bogglingly slow. This little .exe file was vastly faster, and I've come to use it extensively. Unless I get Wine working, this tool will have to stay on my Windows XP partition. It works great, and I haven't found a good linux-based replacement yet.
Time has moved on. Hardware has gotten faster, and the 'java penalty' has reduced markedly. RconJ is actually usable, but I still don't use it. Plus, it would require me to install ConsoleOne onto my laptop. It's 32-bit, so that's actually possible, but I really don't want to do that.
The Remote Console through the Novell Remote Monitor (that service out on :8009) has a nice remote-console utility, but it also requires Java. I'm still biased against java, and java-on-linux still seems fairly unstable to me. I don't trust it yet. It also doesn't scale well. When I'm service-packing, it is a LOT nicer looking to have 6 rconip windows up than 6 browser-based NRM java-consoles open. Plus, rconip will allow me access to the server console if DS is locked, something that NRM can't do and is invaluable in an emergency.
Once the wireless driver problems are fixed, I'll boot the linux side much more often. Remote-X over SSH actually makes some of my remote management a touch easier than it is in WinXP. And if I really really need to use Windows, my work XP VM is accessible over RDesktop. There are a few other non-work reasons why I don't boot Linux very often, but I'll not go into those here.
So, oddly, NetWare is partly responsible for keeping me in Windows at home. But only partly.
1: Wireless driver problems
I have an intel 3945 WLAN card. It works just fine in linux, well supported. What throws it for a loop, however, are sleep and hibernate states. It can go one, two, four, maybe five cycles through sleep before it will require a reboot in order to find the home wireless again. If it doesn't lock the laptop up hard. Since my usage patterns are heavily dependent upon Sleep mode, this is a major, major disincentive to keep the Linux side booted.
I understand the 2.6.25 kernel is a lot better about this particular driver. Thus, I wait with eager anticipation the release of openSUSE 11.0. This driver is currently the ipw3945 driver, and will eventually turn into iwl3945 driver once it comes down the pipe. What little I've read about it suggests that the iwl driver is more stable through power states.
2: NetWare remote console
I use rconip for remote console to NetWare. Back when Novell first created the IP-based rconsole, they also released rconj along side ConsoleOne to provide it. As this was written in Java, it was mind bogglingly slow. This little .exe file was vastly faster, and I've come to use it extensively. Unless I get Wine working, this tool will have to stay on my Windows XP partition. It works great, and I haven't found a good linux-based replacement yet.
Time has moved on. Hardware has gotten faster, and the 'java penalty' has reduced markedly. RconJ is actually usable, but I still don't use it. Plus, it would require me to install ConsoleOne onto my laptop. It's 32-bit, so that's actually possible, but I really don't want to do that.
The Remote Console through the Novell Remote Monitor (that service out on :8009) has a nice remote-console utility, but it also requires Java. I'm still biased against java, and java-on-linux still seems fairly unstable to me. I don't trust it yet. It also doesn't scale well. When I'm service-packing, it is a LOT nicer looking to have 6 rconip windows up than 6 browser-based NRM java-consoles open. Plus, rconip will allow me access to the server console if DS is locked, something that NRM can't do and is invaluable in an emergency.
Once the wireless driver problems are fixed, I'll boot the linux side much more often. Remote-X over SSH actually makes some of my remote management a touch easier than it is in WinXP. And if I really really need to use Windows, my work XP VM is accessible over RDesktop. There are a few other non-work reasons why I don't boot Linux very often, but I'll not go into those here.
So, oddly, NetWare is partly responsible for keeping me in Windows at home. But only partly.
Labels: linux, netware, novell, opinion, virtualization
Monday, March 17, 2008
Today at Brainshare
Monday. Opening day. I had trouble getting to sleep last night due to a poor choice of bed-time reading (don't read action, don't read action, don't read action). And had to get up at 6am body time in order to get breakfast before the morning keynote. There be zombies.
Breakfast was uninspired. As per usual, the hashbrowns had cooled to a gellid mass before I found everything and got a seat.
The Monday keynotes are always the CxO talks about strategy and where we're going. Today a mess of press releases from Novell give a good idea what the talks were about. Hovsepian was first, of course, and was actually funny. He gave some interesting tid-bits of knowledge.
Another thing he mentioned several times in association with Fossa and agility, is mergers and acquisitions. This is not something us Higher Ed types ever have to deal with, but it is an area in .COM land that requires a certain amount of IT agility to accommodate successfully. He mentioned this several times, which suggests that this strategy is aimed squarely at for-profit industry.
Also, SAP has apparently selected SLES as their primary platform for the SMB products.
Pat Hume from SAP also spoke. But as we're on Banner, and it'll take a sub-megaton nuclear strike to get us off of it, I didn't pay attention and used the time to send some emails.
Oh, and Honeywell? They're here because they have hardware that works with IDM. That way the same ID you use for your desktop login can be tied to the RFID card in your pocket that gets you into the datacenter. Spiffy.
ATT375 Advanced Tips & Tricks for Troubleshooting eDir 8.8
A nice session. Hard to summarize. That said, they needed more time as the Laptops with VMWare weren't fast enough for us to get through many of the exercises. They also showed us some nifty iMonitor tricks. And where the high-yield shoot-your-foot-off weapons are kept.
BUS202 Migrating a NetWare Cluster to OES2
Not a good session. The presenter had a short slide deck, and didn't really present anything new to me other than areas where other people have made major mistakes. And to PLAN on having one of the linux migrations go all lost-data on you. He recommended SAN snapshots. It shortly digressed into "Migrating a NetWare Cluster to Linux HA", which is a different session all together. So I left.
TUT215 Integrating Macintosh with Novell
A very good session. The CIO of Novell Canada was presenting it, and he is a skilled speaker. Apparently Novell has written a new AFP stack from scratch for OES2 Sp1, since NETATALK is comparatively dog slow. And, it seems, the AFP stack is currently out performing the NCP stack on OES2 SP1. Whoa! Also, the Banzai GroupWise client for Mac is apparently gorgeous. He also spent quite a long time (18 minutes) on the Kanaka client from Condrey Consulting. The guy who wrote that client was in the back of the room and answered some questions.
Breakfast was uninspired. As per usual, the hashbrowns had cooled to a gellid mass before I found everything and got a seat.
The Monday keynotes are always the CxO talks about strategy and where we're going. Today a mess of press releases from Novell give a good idea what the talks were about. Hovsepian was first, of course, and was actually funny. He gave some interesting tid-bits of knowledge.
- Novell's group of partners is growing, adding a couple hundred new ones since last year. This shows the Novell 'ecosystem' is strong.
- 8700 new customers last year
- Novell press mentions are now only 5% negative.
- High Capacity Computing
- Policy Engines
- Orchestration
- Convergence
- Mobility
Another thing he mentioned several times in association with Fossa and agility, is mergers and acquisitions. This is not something us Higher Ed types ever have to deal with, but it is an area in .COM land that requires a certain amount of IT agility to accommodate successfully. He mentioned this several times, which suggests that this strategy is aimed squarely at for-profit industry.
Also, SAP has apparently selected SLES as their primary platform for the SMB products.
Pat Hume from SAP also spoke. But as we're on Banner, and it'll take a sub-megaton nuclear strike to get us off of it, I didn't pay attention and used the time to send some emails.
Oh, and Honeywell? They're here because they have hardware that works with IDM. That way the same ID you use for your desktop login can be tied to the RFID card in your pocket that gets you into the datacenter. Spiffy.
ATT375 Advanced Tips & Tricks for Troubleshooting eDir 8.8
A nice session. Hard to summarize. That said, they needed more time as the Laptops with VMWare weren't fast enough for us to get through many of the exercises. They also showed us some nifty iMonitor tricks. And where the high-yield shoot-your-foot-off weapons are kept.
BUS202 Migrating a NetWare Cluster to OES2
Not a good session. The presenter had a short slide deck, and didn't really present anything new to me other than areas where other people have made major mistakes. And to PLAN on having one of the linux migrations go all lost-data on you. He recommended SAN snapshots. It shortly digressed into "Migrating a NetWare Cluster to Linux HA", which is a different session all together. So I left.
TUT215 Integrating Macintosh with Novell
A very good session. The CIO of Novell Canada was presenting it, and he is a skilled speaker. Apparently Novell has written a new AFP stack from scratch for OES2 Sp1, since NETATALK is comparatively dog slow. And, it seems, the AFP stack is currently out performing the NCP stack on OES2 SP1. Whoa! Also, the Banzai GroupWise client for Mac is apparently gorgeous. He also spent quite a long time (18 minutes) on the Kanaka client from Condrey Consulting. The guy who wrote that client was in the back of the room and answered some questions.
Labels: brainshare, clustering, netware, novell, OES, sysadmin, virtualization
Thursday, October 25, 2007
Virtualization and security
I've known for a while now that virtualization as it exists in x86 space is not a security barrier. Heck, it was stated outright at BrainShare 2006 when Novell started pushing AppArmor. The Internet Storm Center people had an article on it a month ago. And now we have an opinion from the OpenBSD creator about it, which you can read here.
It sounds like the main reason virtualization isn't a security barrier is because of the CPU architecture. Intel is making advances with this, witness the existence of VT extensions. Also, as virtualization becomes more ubiquitous in the marketplace Intel will start making their CPUs more virtualization-friendly. Which is to say that they're not very VM friendly now.
And as Theo stated in his thread, "if the actual hardware let us do more isolation than we do today, we would actually do it in our operating system." Process separation is its own form of 'virtualization', and is something that is handled in software right now. Anything in software can be subverted by software, so having a hardware enforceable boundary makes things stay where they are put.
Which is why I hold the opinion that you should group virtual-machines with similar security requirements on the same physical hardware, but separate machines subject to different regulations and requirements. Or put another way, do not host the internal Time Card web-server VM on the same hardware as your public web-server, even if they're on completely different networks. Or, do not host HIPPA-subjected VM's on the same ESX cluster as your Blackberry Enterprise Server VM.
Virtualization as it exists now in x86-space does provide a higher barrier to get over to fully subvert the hardware. Groups only interested in the physical resources of a server, such as CPU or disk, may not even need to subvert the hypervisor to get what they want; so no need to break out of jail. Groups intent on thievery of information may have to break out of jail to get what they want, and they'll invest in the technology to do just that.
Warez crews don't give a damned about virtualization, they just want an internet-facing server with lots of disk space they can subvert. That can be a VM or physical server for all they care. They're not the threat, though the resource demands they can place on a physical server may cause problems on on unrelated VM's due to simple resource starvation.
The threat are cabals looking to steal information for resale. They are the ones who will go to the effort to bust out of the VM jail. They're a lot harder to detect since they don't cause huge bandwidth spikes the ways the warez crews do. They've always been our worst enemy, and virtualization doesn't do much at all to prevent them gaining access. In fact, virtualization may ease their problem as we group secure and unsecure information on the same physical hardware.
It sounds like the main reason virtualization isn't a security barrier is because of the CPU architecture. Intel is making advances with this, witness the existence of VT extensions. Also, as virtualization becomes more ubiquitous in the marketplace Intel will start making their CPUs more virtualization-friendly. Which is to say that they're not very VM friendly now.
And as Theo stated in his thread, "if the actual hardware let us do more isolation than we do today, we would actually do it in our operating system." Process separation is its own form of 'virtualization', and is something that is handled in software right now. Anything in software can be subverted by software, so having a hardware enforceable boundary makes things stay where they are put.
Which is why I hold the opinion that you should group virtual-machines with similar security requirements on the same physical hardware, but separate machines subject to different regulations and requirements. Or put another way, do not host the internal Time Card web-server VM on the same hardware as your public web-server, even if they're on completely different networks. Or, do not host HIPPA-subjected VM's on the same ESX cluster as your Blackberry Enterprise Server VM.
Virtualization as it exists now in x86-space does provide a higher barrier to get over to fully subvert the hardware. Groups only interested in the physical resources of a server, such as CPU or disk, may not even need to subvert the hypervisor to get what they want; so no need to break out of jail. Groups intent on thievery of information may have to break out of jail to get what they want, and they'll invest in the technology to do just that.
Warez crews don't give a damned about virtualization, they just want an internet-facing server with lots of disk space they can subvert. That can be a VM or physical server for all they care. They're not the threat, though the resource demands they can place on a physical server may cause problems on on unrelated VM's due to simple resource starvation.
The threat are cabals looking to steal information for resale. They are the ones who will go to the effort to bust out of the VM jail. They're a lot harder to detect since they don't cause huge bandwidth spikes the ways the warez crews do. They've always been our worst enemy, and virtualization doesn't do much at all to prevent them gaining access. In fact, virtualization may ease their problem as we group secure and unsecure information on the same physical hardware.
Labels: opinion, virtualization
Tuesday, October 09, 2007
Xen in 10.3
Because I couldn't get a good video driver working for it, I haven't spent much time in the new Xen. I believe it is Xen 3.1. And yes, it IS a lot faster on the network. Wow. It used to be painful, now it is improved quite a bit. I just patched the windows vm on my work machine, and the network transfer went really fast. Then I had to turn it off since I needed my linux desktop back.
And now I get to see how to convert a Xen disk-image into a vmware disk image. I know it can be done, but I haven't dug up the script or whatever.
And now I get to see how to convert a Xen disk-image into a vmware disk image. I know it can be done, but I haven't dug up the script or whatever.
Labels: linux, virtualization
Friday, October 05, 2007
openSUSE 10.3 is in
No problems, but one. The "nvidia in Xen" problem is back. The prior solution isn't working yet. Unresolved symbols. This could be a work-stopper, or the thing that makes me move all the way to VMWare.
Labels: linux, opensuse, virtualization
Tuesday, October 02, 2007
NCL 2.0 beta and Xen, pt 2
I now have server side and client side captures. The server side shows what's really going on. It is clear that those jumbos I talked about earlier are being disassembled in the Xen network stack. The client traces look similar to this
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
<- Ack
<- Ack
-> NCP to server
<- Ack
With variations on the order. The NCP to server packets are all jumbos. From the server side it looks a lot different. The same sequence from the server side:
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
What's more, the server sees a marked delay in packets between the <- Ack and the first -> NCP to server. On the client side the delays are between the -> NCP to server and the responding <- Ack. I interpret this to show a packet-disassembly delay in the Xen stack.
What I can't figure out is how are the jumbos getting on the network stack at all? The configured network interfaces (except for loopback) in the Dom0 all have MTU values of 1500. I suspect NCL throughput for higher record sizes will improve markedly if it didn't force the Xen layer to disassemble the jumbos. Overriding the MTU on an interface is something that can only be done in kernel-space (I think) which would point to the novfs kernel module.
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
<- Ack
<- Ack
-> NCP to server
<- Ack
With variations on the order. The NCP to server packets are all jumbos. From the server side it looks a lot different. The same sequence from the server side:
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
-> NCP to server
-> NCP to server
-> NCP to server
<- Ack
What's more, the server sees a marked delay in packets between the <- Ack and the first -> NCP to server. On the client side the delays are between the -> NCP to server and the responding <- Ack. I interpret this to show a packet-disassembly delay in the Xen stack.
What I can't figure out is how are the jumbos getting on the network stack at all? The configured network interfaces (except for loopback) in the Dom0 all have MTU values of 1500. I suspect NCL throughput for higher record sizes will improve markedly if it didn't force the Xen layer to disassemble the jumbos. Overriding the MTU on an interface is something that can only be done in kernel-space (I think) which would point to the novfs kernel module.
Labels: linux, novell, virtualization
Monday, October 01, 2007
NCL 2.0 beta and Xen
I found a good candidate for why the Novell Client for Linux 2.0-beta is so crappy in a Xen kernel. Take a look at this:
Frame 6 (4434 bytes on wire, 4434 bytes captured)
What the heck? What it should look like is this:
Frame 6 (1514 bytes on wire, 1514 bytes captured)
So I go to our network guys and ask, "Have we turned on jumbo frames anywhere?" No, we haven't. Anywhere. Which I pretty much knew, since we're not doing any iSCSI. So where the heck is that jumbo coming from? The only thing I can think of is that the sniffing layer I'm getting this at is above the layer that'd grab what actually hits the wire, and something between the sniffer and the wire is converting these jumbos to the normal 1514B ethernet MTU, and that's where my lag is coming from.
This is a case where I'd like to span a port and get a sniff of what actually hits the wire so I can compare.
Frame 6 (4434 bytes on wire, 4434 bytes captured)
What the heck? What it should look like is this:
Frame 6 (1514 bytes on wire, 1514 bytes captured)
So I go to our network guys and ask, "Have we turned on jumbo frames anywhere?" No, we haven't. Anywhere. Which I pretty much knew, since we're not doing any iSCSI. So where the heck is that jumbo coming from? The only thing I can think of is that the sniffing layer I'm getting this at is above the layer that'd grab what actually hits the wire, and something between the sniffer and the wire is converting these jumbos to the normal 1514B ethernet MTU, and that's where my lag is coming from.
This is a case where I'd like to span a port and get a sniff of what actually hits the wire so I can compare.
Labels: linux, novell, virtualization
Monday, September 24, 2007
Virtualization and Security
It's been a few days for it.
Two BrainShare's ago, when I first heard about AppArmor, the guy giving the demo was very, very clear that virtualization is not a security barrier. Especially AppArmor. This may seem a bit contradictory, considering what AppArmor is supposed to do. What he meant was that you should not rely on AppArmor to provide separation between two applications with very different security postures. Physical separation is best.
That extends to full virtualization products like VMWare or XenSource. On Saturday the Internet Storm Center had a nice diary entry on this very topic. To summarize, Malware already detects virtual machines and changes its behavior accordingly. Last Friday, VMWare released a patch for ESX server that fixes some very interesting security problems. The patch also links to CVE-2007-4496, which is well worth a read. In short, an administrative-user in a guest OS can corrupt memory or possibly execute code in the Host OS. These are the kind of vulnerabilities that I'm worried about.
Any time you run on shared hardware the possibility exists of 'leaking' across instances. Virtualization on x86 is still primitive enough that that the barriers between guest OS instances aren't nearly as high as they are on, say, IBM Mainframes which have been doing this sort of thing since the 1960's. I fully expect Intel (and AMD if they can keep up) to make the x86 CPU ever more virtualization friendly. But until we get to robust hardware enforcement of separation between guest OS instances, we'll have to do the heavy lifting in software.
Which means that a good best-practice is to restrict the guests that can run on a specific virtualization host or cluster to servers with similar security postures. Do not mix the general web-server with the credit-card processing server (PCI). Or mix the credit-card processing server (PCI) with the web interface to your Medical records (HIPPA). Or mix the bugzilla web-server for internal development (trade secrets) with the general support web-server.
Yes, this does reduce the 'pay-back' for using virtualization technology in the first place. However, it is a better posture. Considering the rate of adoption of VM technology in the industry, I'm pretty sure the black-hat crowd is actively working on ways to subvert VM hosts through the guests.
Two BrainShare's ago, when I first heard about AppArmor, the guy giving the demo was very, very clear that virtualization is not a security barrier. Especially AppArmor. This may seem a bit contradictory, considering what AppArmor is supposed to do. What he meant was that you should not rely on AppArmor to provide separation between two applications with very different security postures. Physical separation is best.
That extends to full virtualization products like VMWare or XenSource. On Saturday the Internet Storm Center had a nice diary entry on this very topic. To summarize, Malware already detects virtual machines and changes its behavior accordingly. Last Friday, VMWare released a patch for ESX server that fixes some very interesting security problems. The patch also links to CVE-2007-4496, which is well worth a read. In short, an administrative-user in a guest OS can corrupt memory or possibly execute code in the Host OS. These are the kind of vulnerabilities that I'm worried about.
Any time you run on shared hardware the possibility exists of 'leaking' across instances. Virtualization on x86 is still primitive enough that that the barriers between guest OS instances aren't nearly as high as they are on, say, IBM Mainframes which have been doing this sort of thing since the 1960's. I fully expect Intel (and AMD if they can keep up) to make the x86 CPU ever more virtualization friendly. But until we get to robust hardware enforcement of separation between guest OS instances, we'll have to do the heavy lifting in software.
Which means that a good best-practice is to restrict the guests that can run on a specific virtualization host or cluster to servers with similar security postures. Do not mix the general web-server with the credit-card processing server (PCI). Or mix the credit-card processing server (PCI) with the web interface to your Medical records (HIPPA). Or mix the bugzilla web-server for internal development (trade secrets) with the general support web-server.
Yes, this does reduce the 'pay-back' for using virtualization technology in the first place. However, it is a better posture. Considering the rate of adoption of VM technology in the industry, I'm pretty sure the black-hat crowd is actively working on ways to subvert VM hosts through the guests.
Labels: brainshare, virtualization
Tuesday, September 18, 2007
OES2: clustering
I made a cluster inside Xen! Two NetWare VM's inside a Xen container. I had to use a SAN LUN as the shared device since I couldn't make it work doing it just to a single file. Not sure what's up with that. But, it's a cluster, the volume moves between the two just fine.
Another thing about speeds, now that I have some data to play with. I copied a bunch of user directory data over to the shared LUN. It's a piddly 10GB LUN so it filled quick. That's OK, it should give me some ideas of transfer times. Doing a TSATEST backup from one cluster-node to the other (i.e. inside the Xen bridge) gave me speeds on the order of 1000MB/Min. Doing a TSATEST backup from a server in our production tree to the cluster node (i.e. over the LAN) gave me speeds of about 350MB/Min. Not so good.
For comparison, doing a TSATEST backup from the same host only drawing data from one of the USER volumes on the EVA (highly fragmented, but must faster, storage) gives a rate of 550 MB/Min.
I also discovered the VAST DIFFERENCES between our production eDirectory tree, which has been in existence since 1995 if the creation timestamp on the tree object is to be believed, and the brand new eDir 8.8 tree the OES2 cluster is living in. We have a heckova lot more attributes and classes in the prod tree than in this new one. Whoa. It made for some interesting challenges when importing users into it.
Another thing about speeds, now that I have some data to play with. I copied a bunch of user directory data over to the shared LUN. It's a piddly 10GB LUN so it filled quick. That's OK, it should give me some ideas of transfer times. Doing a TSATEST backup from one cluster-node to the other (i.e. inside the Xen bridge) gave me speeds on the order of 1000MB/Min. Doing a TSATEST backup from a server in our production tree to the cluster node (i.e. over the LAN) gave me speeds of about 350MB/Min. Not so good.
For comparison, doing a TSATEST backup from the same host only drawing data from one of the USER volumes on the EVA (highly fragmented, but must faster, storage) gives a rate of 550 MB/Min.
I also discovered the VAST DIFFERENCES between our production eDirectory tree, which has been in existence since 1995 if the creation timestamp on the tree object is to be believed, and the brand new eDir 8.8 tree the OES2 cluster is living in. We have a heckova lot more attributes and classes in the prod tree than in this new one. Whoa. It made for some interesting challenges when importing users into it.
Labels: clustering, netware, novell, OES, virtualization
Thursday, September 13, 2007
OES2: virtualization
I have the beta up and running. I have a pair of OES2-NW servers running in Xen on SLES10SP1. And it loads just spiffy. Haven't done any performance testing on it, kind of hard to really interpret results at this point anyway.
What I HAVE been spending time on is seeing if it is possible to get a cluster set up. Clusters, of course, rely on shared storage. And if it works the way I need it to work, I need multiple Xen machines talking to the same LUNs. It may be doable, but I'm having a hard time figuring it out. The documentation on Xen isn't what you'd call complete. Novell has some in the SLES10SP1 documentation, but the stuff in the OES2 documentation is... decidedly overview-oriented. This is the most annoying thing, as I can't just put my nose to a manual and find it.
So, looking for Xen manual. It has to be around somewhere. Google-foo failed me today.
What I HAVE been spending time on is seeing if it is possible to get a cluster set up. Clusters, of course, rely on shared storage. And if it works the way I need it to work, I need multiple Xen machines talking to the same LUNs. It may be doable, but I'm having a hard time figuring it out. The documentation on Xen isn't what you'd call complete. Novell has some in the SLES10SP1 documentation, but the stuff in the OES2 documentation is... decidedly overview-oriented. This is the most annoying thing, as I can't just put my nose to a manual and find it.
So, looking for Xen manual. It has to be around somewhere. Google-foo failed me today.
Labels: netware, novell, OES, virtualization
Friday, July 20, 2007
SUSE driver pack for windows
Novell released the "SUSE Linux Enterprise Virtual Machine Driver Pack" today. You can find it on the downloads site. A word of warning, though, from the Documentation:
But, the fact that they've released it is great. Also, they list Windows XP drivers as part of the download. Yay!
So, you can't run it on openSUSE (different kernel), and since SLES10 SP1 has already had a kernel update, you can't use it THERE without a subscription. So no freebie.1.9 Avoiding Problems with the Drivers
[...]
- Upgrading the Linux* kernel of the virtual machine host without upgrading the driver pack at the same time.
But, the fact that they've released it is great. Also, they list Windows XP drivers as part of the download. Yay!
Labels: novell, suse, virtualization
Monday, July 09, 2007
More fun OES2 tricks
I had an idea while I was googling around a bit ago. This may not work the way I expect as I'm not 100% on the technologies involved. But it sounds feasible.
Lets say you want to create a cluster mirror of a 2-node cluster for disaster recovery purposes. This will need at least four servers to set up. You have shared storage for both cluster pairs. So far so good.
Create the four servers as OES2-Linux servers. Set up the shared storage as needed so everything can see what it should in each site. Use DRBD to create new block-devices that'll be mirrored between the cluster pairs. Then set up NetWare-in-VM on each server, using the DRBD block-devices as the Cluster disk devices. You could even do SYS: on the DRBD block-devices if you want a true cluster-clone. That way when disk I/O happens on the clustered resources it gets replicated asynchronously to the DR site; unlike software RAID1 the I/O is considered committed when it hits local storage, SW RAID1 only considers writes committed when all mirrored LUNs report the commit.
Then, if the primary site ever dies, you can bring up an exact replica of the primary cluster, only on the secondary cluster pair. Key details like how to get the same network in both locations I leave as an exercise for the Cisco engineers. But still, an interesting idea.
Lets say you want to create a cluster mirror of a 2-node cluster for disaster recovery purposes. This will need at least four servers to set up. You have shared storage for both cluster pairs. So far so good.
Create the four servers as OES2-Linux servers. Set up the shared storage as needed so everything can see what it should in each site. Use DRBD to create new block-devices that'll be mirrored between the cluster pairs. Then set up NetWare-in-VM on each server, using the DRBD block-devices as the Cluster disk devices. You could even do SYS: on the DRBD block-devices if you want a true cluster-clone. That way when disk I/O happens on the clustered resources it gets replicated asynchronously to the DR site; unlike software RAID1 the I/O is considered committed when it hits local storage, SW RAID1 only considers writes committed when all mirrored LUNs report the commit.
Then, if the primary site ever dies, you can bring up an exact replica of the primary cluster, only on the secondary cluster pair. Key details like how to get the same network in both locations I leave as an exercise for the Cisco engineers. But still, an interesting idea.
Labels: clustering, netware, novell, OES, virtualization
Tuesday, July 03, 2007
OES2: pushed several months
A new post up on Cool Blogs shows where OES2 is sitting:
http://www.novell.com/coolblogs/?p=921
To quote from one of the comments by the author:
Crap.
http://www.novell.com/coolblogs/?p=921
To quote from one of the comments by the author:
There will be a public beta. It might take couple of months more for a public beta.This blows my schedule. From the sounds of it, they're looking at a Christmas or possibly BrainShare 2008 release. We'll have to put NetWare inside ESX server instead of a Xen paravirtualization. Due to this delay, and the presumed SP1 schedule, chances are now much worse for Novell to make the summer intersession 2008 migration window.
Crap.
Labels: netware, novell, OES, virtualization
Wednesday, June 13, 2007
Still waiting
Any day now OES2 will come out.
Any day now.
Any day now I'll get a paravirtualizable NetWare and will be able to run it through its paces.
Any day now I'll get to try and figure out how Xen virtualization of NetWare interacts with an HP MSA1500cs.
But not today.
Any day now.
Any day now I'll get a paravirtualizable NetWare and will be able to run it through its paces.
Any day now I'll get to try and figure out how Xen virtualization of NetWare interacts with an HP MSA1500cs.
But not today.
Labels: msa, netware, novell, OES, virtualization
Tuesday, March 20, 2007
TUT211: NetWare virtualization
- Xen 3.0.4+ is the codebase. They wanted 3.0.5, but Xensource didn't get the release out in time for that.
- Server.EXE contains the bulk of the paravirtualization code.
- New loader, XNLOADER.SYS replaces NWLOADER.SYS, if used in Xen.
- New console driver. The old method, writing directly to video memory, won't work in a paravirtualized VM.
- New PSM: XENMP.PSM. Permits SMP in Xen.
- So far, no "P2V" equivalent application, though they promise something by OES2-ship.
- Improved VM management screens.
Labels: brainshare, netware, novell, OES, virtualization
Friday, March 16, 2007
Xen, cdroms, and tricks
One of the things I managed to figure out today is how to get a DVD drive visible in a Xen DomU, and how to tell the DomU that the media has been changed. First off, configuring your VM to have an optical drive in the first place.
Unknown to me until now, there is a key-combination that allows you to manage the devices in a DomU.
[ctrl]+[alt]+[2]
That will take you to the HVM management screen. Type 'help' for what commands you can issue here. To tell the DomU that the optical device is ejected:
Then change your media, and at the same screen, issue the command:
To get back to the graphical screen:
disk = [ 'phy:/dev/sdb5,ioemu:hda,w','phy:/dev/sr0,hdc:cdrom,r']The second command is the one that attached the physical drive to the DomU. That'll give you a CD device in your DomU. Unless you have a disk in the drive when the DomU is started, you won't see anything. Here is where the next bit comes in.
Unknown to me until now, there is a key-combination that allows you to manage the devices in a DomU.
[ctrl]+[alt]+[2]
That will take you to the HVM management screen. Type 'help' for what commands you can issue here. To tell the DomU that the optical device is ejected:
eject hdcWhere "hdc" is the device you configured in your VM config file.
Then change your media, and at the same screen, issue the command:
change hdc /dev/sr0This tells the DomU that the optical device has new media, and to scan it.
To get back to the graphical screen:
[ctrl]+[alt]+[1]This screen works similar to the NetWare debugger, in that all processing in the VM stops when you're in there. The eject command causes processing in the VM enough to process the eject, but not enough to run all the other processes. So beaware that time-sync will get screwed if you stay in the screen too long.
Labels: virtualization
Monday, February 12, 2007
Novell, Microsoft, and Xen
Novell put out a press release today.
It turns out that Intel has worked out some drivers for use by Windows inside a Xen paravirtualized container. This is distinct from the 'full virtualization' possible only in conjunction with things like the Intel VT instructions. I expected this to maybe be ready in time for SLES10 SP1, if we were lucky.
This is of great interest to me. I'm running windows on Xen right now, in full mode. Network performance is decidedly poor, though the rest of it works reasonably well. I'd like to run it paravirtualized if at all possible as that runs faster. Unfortunately, the drivers mentioned in the PR aren't generally available.
It turns out that Intel has worked out some drivers for use by Windows inside a Xen paravirtualized container. This is distinct from the 'full virtualization' possible only in conjunction with things like the Intel VT instructions. I expected this to maybe be ready in time for SLES10 SP1, if we were lucky.
This is of great interest to me. I'm running windows on Xen right now, in full mode. Network performance is decidedly poor, though the rest of it works reasonably well. I'd like to run it paravirtualized if at all possible as that runs faster. Unfortunately, the drivers mentioned in the PR aren't generally available.
Labels: microsoft, novell, virtualization
Monday, January 29, 2007
An incompatibility
I've been working on Zen Asset Management 7.5 the past few days. In the process I discovered a rather significant incompatibility with the client. Well, significant for me since it'll make client testing harder.
When run on a Windows XP virtual machine running on Xen 3.0.3 that comes with openSUSE 10.2, it causes the clock in the VM to slow w-a-y down. On the order of 1 tick per 30 ticks on the host machine slow. This makes it unusable in a rather significant way.
It also is completely unfixable! Running Windows in a full VM in Xen on openSUSE 10.2 is an unsupported operation. I have the CPU for it, and it runs pretty well in every other way. But something the inventory process does causes some Xen emulation to go 'poink' in a bad way. It is so bad that even after the VM is powered off and the BIOS is putting the virtual machine to rest, it STILL takes a very long time for the VM to unload. No idea where to report this one.
In general, the product looks interesting. Getting it rolled out everywhere will take a lot of work. Plus, for some reason it isn't accepting my license code. But that's something that can be fixed with a call in to Novell.
When run on a Windows XP virtual machine running on Xen 3.0.3 that comes with openSUSE 10.2, it causes the clock in the VM to slow w-a-y down. On the order of 1 tick per 30 ticks on the host machine slow. This makes it unusable in a rather significant way.
It also is completely unfixable! Running Windows in a full VM in Xen on openSUSE 10.2 is an unsupported operation. I have the CPU for it, and it runs pretty well in every other way. But something the inventory process does causes some Xen emulation to go 'poink' in a bad way. It is so bad that even after the VM is powered off and the BIOS is putting the virtual machine to rest, it STILL takes a very long time for the VM to unload. No idea where to report this one.
In general, the product looks interesting. Getting it rolled out everywhere will take a lot of work. Plus, for some reason it isn't accepting my license code. But that's something that can be fixed with a call in to Novell.
Labels: opensuse, virtualization, zenworks
Tuesday, November 21, 2006
Virtual Machines are not a security barrier
Several of the sessions I attended at BrainShare this year were on AppArmor. The project lead for that product presented several times, and several times he repeated this mantra. A Virtual Machine is not a security barrier. This is true for full-virtualization products such as VMWare, and paravirtualization such as Xen.
Yesterday's SANS diary had an entry about VM detection on the part of malware. As you can well imagine, spyware and adware researchers make great use of products like VMWare to analyze their prey. VMWare has handy snapshoting abilities, which makes reverting your VM to pre-infection state easy. Unfortunately for them, "3 out of 12 malware specimens recently captured in our honeypot refused to run in VMware." The bad-ware authors are also aware of this and program their stuff to not run.
What's more insidious is that there are cases where the malware doesn't use the VMware detection to not run, but to infect the HOST machine instead. While this may not affect something like ESX Server which is a custom OS, other products like Xen in full virtualization mode or VMWare Server running on Windows or Linux would be exposed this way. Figuring out that your malware process is running in a virtual machine is easy and scriptable, and breaking out of the VM is just as scriptable.
Virtual Machines are not a security barrier, nor do they make you significantly safer. They're just different.
Tags: malware, brainshare, virtualization
Yesterday's SANS diary had an entry about VM detection on the part of malware. As you can well imagine, spyware and adware researchers make great use of products like VMWare to analyze their prey. VMWare has handy snapshoting abilities, which makes reverting your VM to pre-infection state easy. Unfortunately for them, "3 out of 12 malware specimens recently captured in our honeypot refused to run in VMware." The bad-ware authors are also aware of this and program their stuff to not run.
What's more insidious is that there are cases where the malware doesn't use the VMware detection to not run, but to infect the HOST machine instead. While this may not affect something like ESX Server which is a custom OS, other products like Xen in full virtualization mode or VMWare Server running on Windows or Linux would be exposed this way. Figuring out that your malware process is running in a virtual machine is easy and scriptable, and breaking out of the VM is just as scriptable.
Virtual Machines are not a security barrier, nor do they make you significantly safer. They're just different.
Tags: malware, brainshare, virtualization
Labels: brainshare, malware, virtualization
