"J. Roeleveld" <jo...@antarean.org> writes: > On Wednesday, January 20, 2016 01:46:29 AM lee wrote: >> "J. Roeleveld" <jo...@antarean.org> writes: >> > On Tuesday, January 19, 2016 01:46:45 AM lee wrote: >> >> "J. Roeleveld" <jo...@antarean.org> writes: >> >> > On Monday, January 18, 2016 02:02:27 AM lee wrote: >> >> >> "J. Roeleveld" <jo...@antarean.org> writes: > >> >> > >> >> > Yes >> >> > >> >> >> That would be a huge waste of resources, >> >> > >> >> > Diskspace and CPU can easily be overcommitted. >> >> >> >> Overcommitting disk space sounds like a very bad idea. Overcommitting >> >> memory is not possible with xen. >> > >> > Overcommitting diskspace isn't such a bad idea, considering most installs >> > never utilize all the available diskspace. >> >> When they do not use it anyway, there is no reason to give it to them in >> the first place. And when they do use it, how do the VMs handle the >> problem that they have plenty disk space available, from their point of >> view, while the host which they don't know about doesn't allow them to >> use it? > > 1 word: Monitoring. > When you overcommit any resource, you need to put monitoring in place. > Then you also need to ensure you have the ability to increase that resource > when required.
So you more or less frequently shrink your VMs back when the monitoring informs you that you need to do that? Isn't it more reasonable not to overcommit but to increase the resource when required? >> Besides, overcommitting disk space means to intentionally create a setup >> which involves that the host can run out of disk space easily. That is >> not something I would want to create for a host which is required to >> function reliably. > > The host should not crash when a VM does or when the storage assigned to VMs > fills up. > If it does, go back to the drawing board and fix your design. I didn't say that the host would crash. I wouldn't consider a VM which is bound to run out of disk space as reliable, especially when it is bound run out of disk space because other VMs which are also bound to run out of disk space use the disk space which the VM would need that's running out. >> And how much do you need to worry about the security of the VMs when you >> build in a way for the users to bring the whole machine, or at least >> random VMs, down by using the disk space which has been assigned to >> them? The users are somewhat likely to do that even unintentionally, >> the more the more you overcommit. > > See comment about monitoring. > If all your users tend to fill up all available diskspace, you obviously can > not overcommit on diskspace. Have you ever seen a disk that doesn't fill up, the larger the disk, the more it fills? >> > Overcommitting memory is, i think, on the roadmap for Xen. (Disclaimer: At >> > least, I seem to remember reading that somewhere) >> >> That would be a nice feature. > > For VDIs, I might consider using it. > But considering most OSs tend to fill up all available memory with caches, I > expect performance issues. It depends on how you use it. >> >> >> plus having to take care of a lot of VMs, >> >> > >> >> > Automated. >> >> >> >> Like how? >> > >> > How do you manage a large amount of physical machines? >> > Just change physical to VMs and do it the same. >> > With VMs you have more options for automation. >> >> Individually, in lack of a better way. Per user when it comes to >> setting up their MUAs and the like, in lack of any better way. It >> doesn't make a difference if it's a VM or not, provided that you have >> remote access to the machine. > > This is where management tools come into play. (Same methods apply to > physical > and virtual) > > When talking MS Windows, domains with their policies are very useful. Couple > that with WSUS for the patching and software distribution tools for the > additional software installs, and you have a very nice setup. I don't like what they call "domains". They tend to get in the way, and when you want to take a machine out of one, all the users need to be set up anew. Is WSUS of any use without domains? If it is, I should take a look at it. > For Linux, I would recommend tools like Ansible or Puppet to control the > software on the machines. Does it really have an advantage over logging in remotely? > For any OS, I would prevent my users from installing random software. And > what > is installed, would be mostly pre-configured out-of-the-box. And how do you preconfigure everything for each user? It would sure be nice if I could, say, install seamonkey and have every existing and new user set up they way they are supposed to be set up without having to do that for every user individually, on a number of VMs. >> When you one VM for many users, you install the MUA only once, and when >> you need to do updates, you do them only once. When you have many VMs, >> like one for each user, you have to install and update many times, once >> on each VM. > > Management tools. like? >> > Depends on the requirements. It's cheaper then a few hundred seperate >> > windows licenses. >> >> It's still more expensive than one, or than a handful, isn't it? > > The same cost applies to running physical boxes instead of VMs. And it is cheaper to use either a VM or a physical machine for 10 users than it is to run 10 VMs or physical machines for one user each. >> > Last time I had to fully reinstall a windows machine it took me a day to >> > do >> > all the updates. Microsoft even has server software that will keep them >> > locally and push them to the clients. >> >> That would be useful to have. Where could I download that? >> >> Last time I installed a VM, it took a week until the updates where >> finally installed, and you have to check on it every now and then to >> find out if it's even doing anything at all. The time before, it wasn't >> a VM but a very slow machine, and that also took a week. You can have >> the fastest machine on the world and Windoze always manages to bring it >> down to a slowness we wouldn't have accepted even 20 years ago. > > Google for "WSUS". > It's been around for a very long time now (since 2005). I just did, and it might be useful. I never heard about it before. >> >> The hardware has already been replaced, and the problem persists. Other >> >> machines of identical hardware that don't run xen don't show any issues. >> > >> > I still say the hardware is buggy. With replacing, I meant replace it with >> > different hardware, not a different version of the same buggy stuff. >> >> The hardware is known to be 100% reliable by own experience for over a >> year, for all the machines. Only when xen is running, the problem shows >> up. >> >> Replacing the machine with another, identical one, allows to rule out >> that the particular machine which was replaced has an issue and was very >> easy to do, so that was a very reasonable second step after trying >> different network cards. Three different network cards, from three >> different manufactures, lead to the same error message. >> >> Googling the error message shows that quite a few ppl, with entirely >> different hardware, usually not running xen, have had the same message >> with very similar symptoms. >> >> This currently leaves these possibilities: >> >> >> 1.) Xen doesn't work with this hardware. > > Xen doesn't touch the network interfaces, it's the host that handles that. And it doesn't have any influence whatsoever that the host itself is running under xen? >> 2.) The problem might somehow be caused by an SSD. > > Network issues caused by SSD? > Sounds like buggy hardware, replace. I don't know what causes the issue, I'm only seeing the symptoms, and I don't know exactly what symptoms I'm supposed to see when the sending queue of the network card times out. Maybe it times out because there's a problem with the SSD, who knows. >> 3.) The error message is actually true and something yet unknown is >> going on on the network. >> >> 4.) The problem may have been fixed a while ago in the kernel and has >> not been fixed in the xen kernel. > > Xen kernel? > I use hardened-sources or gentoo-sources for the host. > Which Xen kernel are you talking about? The one you boot after you installed xen. >> 5.) The gplpv drivers the VMs use cause the problem. > > Contact the developer to get a debug-version. I doubt they can be contacted. There are probably lots of ppl using these drivers, and they don't seem to have this problem. >> 6.) It's an issue with power management since the problem occurs when >> the machine and the VMs are not used/busy, at night. Disabling the >> power management for the network card has not made a difference, >> though. > > Powermanagement of the switches? Hm, that could be an issue, too, I haven't thought of that. This might be a good point since all of the switches the machine was connected to before were from the same manufacturer. >> 3.) is currently being worked on. It needs to be figured out and, if >> there's something weird going on, to be solved in any case. 6.) seems >> unlikely, 1.) and 2.) can be decided when the the hardware is replaced >> with something entirely different, which is the most painful and most >> time-consuming option. That would leave 4.) and 5.), and 3.) if 3.) >> cannot be resolved. >> >> It's easy to say that "the hardware is buggy". I'm not convinced that >> it is. In any case, you can always run into a situation in which xen >> doesn't work as well as you might wish or have experienced so far. > > Hardware should do what it's designed to do. > If it can't handle the function it is build for, it's buggy. So far, it is unknown whether it can handle this function or not. >> >> It's time consuming when you have to reinstall the VMs to migrate them >> >> to kvm. And when you don't have the installers of all the software >> >> that's on some of the VMs and can't get them, you either have to run >> >> them without virtio drivers or you can't migrate them. >> > >> > There are Howtos on the internet describing how to migrate VMs from 1 >> > technology to another. Shouldn't be too hard. >> >> I looked for them. Did you find one that tells you how to install >> the virtio drivers on an existing Windoze 7 VM and that actually works? >> It's already very difficult to get rid of gplpv drivers. > > The following usually works: > Boot up in safe mode, delete the drivers, reboot, install virtio, reboot. IIRC I tried that, and it tends to say that I can't remove these drivers in safe mode. I also can't install them other than when booting into the repair options because when virtio is enabled, the device the drivers are needed for is unavailable and doesn't show up before the drivers are installed. That leaves me with repair mode as the only option to "install" the drivers, but they aren't installed and only used during the repair mode. You can do a repair with the drivers upplied, and it still won't boot after that. These drivers don't have an installer, and the only way to get them installed seems to be by providing them during the installation of the OS, which is pointless because it's already installed. >> > And keeping the installers at hand is, in my opinion, a requirement of >> > sane >> > system management. >> > I have installers for all the versions of software I deal with. >> >> Indeed --- but some predecessor decided not to keep an installer which >> would be required and is now unavailable. So the only options are to >> leave the VM running under xen or to run it under KVM without virtio >> drivers. The latter is bad idea because the application the installer >> would be needed for already has severe performance problems built in, >> and making it worse isn't a good idea. > > Request installers from the original source? They don't give them out anymore, they want to sell more recent versions instead, which are very likely not even capable to let you continue to work with the data from the previous version. I guess their software is so crappy that they are clutching at straws to sell it. > Or consider it legacy and migrate away soonish. That's the most reasonable consideration. > What is your recovery plan if the server it's on dies a horrible death? I have some copies of the VM, and the software creates backups which allow to use such a copy without loosing the data. >> >> > The biggest reason why I don't use KVM is the lack of full snapshot >> >> > functionality. Snapshotting disks is nice, but you end up with an >> >> > unclean- >> >> > shutdown situation and anything that's not yet committed to disk is >> >> > gone. >> >> >> >> I'm not sure what you mean. When you take a snapshot while the VM is not >> >> shut down, what difference does it make whether you use xen or kvm? >> > >> > A "snapshot" for KVM is ONLY the disks. >> > With Xen, VMWare and Virtualbox, I can also make a snapshot/copy of what's >> > in memory. It's that which makes the difference. >> >> Is that possible without freezing the VM while you make a snapshot of >> the memory? > > No > >> If not, how is it so much better than shutting the VM down? > > It's faster in most cases. That much faster? > Exception being, the VM having such a large amount of memory assigned that > the > disk-I/O to store the memory takes longer than a reboot. > > Or, in my usual use-case for needing snapshots, is in the middle of a lengthy > manual process, I want to take a snapshot of the current situation and a > reboot at that point in time will actually cause issues. > The software being used is usually in memory and a disk-only snapshot (eg. > system crashed simulation when restoring) will mean I can start over. Hm, I see ... kvm should have this feature, too. >> >> >> Then there's the question how well vnc or spice connections work over >> >> >> a >> >> >> VPN that goes over the internet. >> >> > >> >> > VNC works quite well, as long as you use a minimal desktop. (like >> >> > blackbox). Don't expect KDE or Gnome to be usable. >> >> > I haven't tried Spice yet, but I've read that it performs better. >> >> >> >> It's not like you had a choice when you have Windoze VMs. >> > >> > Windows has RDP, which is a lot better than VNC. Especially when dealing >> > with low-bandwidth connections. >> >> Wasn't RPD deprecated earlier in this discussion because it seemed to be >> not sufficiently secure? > > Login to the RDP session can be linked to 2FA or smart-cards which need to be > plugged into the laptop. > Don't ask me how, but I have seen it work. > > Couple that with a VPN (Which I consider an absolute must when allowing > employees to work from elsewhere via the internet). > > It can be made more secure than a simple VNC or NX connection. So what do you use to make RDP connections to a Linux machine? >> >> > That depends on where you are. >> >> >> >> In this country, you have to be really lucky to find a place where you >> >> can get a decent internet connection. >> > >> > Then in your country, working from home might not be the best option. >> >> That probably goes for most countries. > > Probably, I tend to only deal with countries in Europe and the US. This does > make me less clued up of the reality in other regions. "Most countries" includes the European ones. >> >> > The company could host the servers in a decent datacentre, which should >> >> > take care of the bandwidth issues. >> >> >> >> And give all their data out of hands? And how much does that cost? >> > >> > I'm talking about putting your own hardware there, not letting the >> > datacentre company access to the servers. >> >> How could they reside in a datacenter without the ppl there having >> physical access to them? > > Locked cages which you provide and control access to? Then you would need to go to or to send someone to the datacenter whenever you need to touch the hardware. > If you're worried about people sniffing encrypted network traffic, I would > say, > good luck building your own secure WAN. > >> >> > For the employees, if they want to work from home, it's up to them to >> >> > ensure they have a reliable connection. >> >> >> >> It is as much problem of the company when they want the employees to >> >> work at home. And the employees don't have a choice, they can only get >> >> a connection they can get. >> > >> > If the company insists people work from home, they need to ensure the >> > employees have the option for a usable connection. Most companies I deal >> > with leave working from home as an option to the employees. >> >> Sometimes it's not an option, and there isn't anything a company could >> do to improve what internet connection an employee can get, unless >> they'd spend huge amounts of money to put cables or fiber glass into the >> ground, provided that they'd get the permissions for that. > > Then the company doesn't have the right to force it onto their employees. as if they'd care >> Sooner or later, it might become very difficult to find anyone who's >> still willing to spend all the time and money it takes to commute, or >> someone who can still afford it at all, and it might become difficult to >> find an employer willing to spend the money it takes to provide the >> employees with offices. > > True, but if you end up paying for the privilege to work, why work at all? > If I would end up with a negative balance because my costs are more then my > income, I would quit on the spot and actually be better off. indeed >> When you consider the enormous amount of resources that are wasted for >> commuting in an economy and that some economies might start to gain an >> advantage over others by letting ppl work from their homes and by thus >> becoming able to make more competitive offers to their customers, you >> might come to think that it won't take very long before almost everyone >> must work at their home. So this isn't a problem of a company, or some >> companies, it's a problem for all companies and all employees, as it is >> a problem for all economies and all countries. > > Countries where the infrastructure already exists will have this as an > advantage. Currently, these are also the countries with the higher wages. And in which country does this kind of infrastructure already exist? > If low-salary countries want to be able to compete on that level, the leaders > of those countries should invest in the infrastructure, instead of their own > fleet of expensive cars, private planes, castles,.... as if they care None of the leaders of any country does that. They should do lots of things. >> >> >> It might work in theory. How would it be feasible in practise? >> >> > >> >> > Plenty of companies do it this way. If you don't want to pay for >> >> > software >> >> > like XenDesktop, you need to do all the work setting it up yourself. >> >> >> >> VNC is somewhat slow over a 1Gbit LAN. Did they find some way to >> >> overcome this problem? >> > >> > Depends on the settings. >> >> Well, yes, I guess you can send something like 640x480 with some minimum >> content that changes as little as possible with less trouble over an >> internet connection than something one can actually work with. > > Try, lower quality, like less colours. That looks ugly, and it quickly goes so bad that it becomes unusable. The times when green/black, goldenrod/black, bw and monochrome displays were used are long gone. > When configured for LAN-settings, a 640x480 VNC session will perform worse > then > a 1280x1024 VNC session configured for 58k. > Difference is, the larger screen looks horrible, but I can still work on it. That depends on what you're doing. When you can't easily read your sources because the syntax highlighting makes things unreadable because the colours suck or when you need to be able to see the images you're working with, the display isn't very useful. Besides, 1280x1024 is an awfully low resolution which is unusable to begin with. >> >> This sounds like it is for people with unlimited resources. >> >> >> >> BTW, access a VM through VNC, and you don't even have any way to make >> >> the mouse pointer in the VNC window actually follow the mouse pointer >> >> you're using, which makes it rather annoying to do anything in the VM >> >> you're looking at. If you found a solution for that, I'd be curious as >> >> to how you solved this problem. >> > >> > There is, it's even documented. >> > I'm assuming you are talking about the VNC-console Xen provides? >> > >> > Configure the mouse to be a tablet in the VM config and the issue >> > disappears. >> Thanks, I can try that. I haven't seen this documented anywhere yet. > > Google for "xen vnc mouse out of sync" > > First hit: > http://www.virtuatopia.com/index.php/Xen_mouse_pointer_appears_in_the_wrong_position_in_VNC_console > > Second hit: > http://xen.1045712.n5.nabble.com/vnc-mouse-out-of-sync-td2588371.html > (See 1st reply) I googled for it, just with slightly different terms. I consider it as a problem of the (particular) vnc client that it doesn't have a way to keep the mouse pointers aligned, so I searched for that. Why would I think that it is a xen specific problem (is it?)?
