Search results

also tried under /zpool/ directly, the only thing I didnt try. doenst work, with thin provision on or off, with Disk Images deselected only leaving Container, and rebooting. Any help appreciated.

And i destroyed the ZFS cuz it was on /rpool/ROOT/pve-1, and put it on /rpool/ROOT, rebooted, still cant choose it. Forgot to remove "disk images" from the content to leave only "Container", so removed that, rebooted again, and STILL cant choose ZFS from the CT create dialog.Looking around...

Didnt work for me, still cant choose anything but local for containers. In fact, I went back and made sure ONLY "Container" (not "Containers" as Proxmox support said here) was allowed in the list of types for the ZFS, and rebooted again, and still can't select it.

Of course. Just didnt want to have to modify them, and use a trusted image from proxmox with it's reputation behind it instead ;) I've modified it slightly for my uses. Thanks.

true enough, sorry, but I saw many posts here pointing to such images for 64 bit use - are there any created by Proxmox that are suitable for use as 64 bit containers? Is there really such a huge loss in ram due to 64 bit that they're not supplied? Would be great to have them in the templates...

the debian 7.0 minimal template here: http://wiki.openvz.org/Download/template/precreated ie http://download.openvz.org/template/precreated/debian-7.0-x86_64-minimal.tar.gz is debian 7.6 per /etc/debian_version (so why not name it as such?) Same deal with the 'full' image...

old thread, sorry but this is the first ive seen that discusses what I need - and this is relevant. you have to manually edit the fstab on each container to mount the shared mountpoint? I actually dont want it shared, I wanted to split out an ssd as a seperate mount on each container - which...

hmm true enough. how about a bind mount to another dir for each image then? the bind mount would only be for external viewpoint, the dirs in private/### would be left as is (the vz id #) - any issues with that?

how about in /var/lib/vz/private/? can I mv 100 $name; ln -s $name 100 ok?

I previously posted about renaming instances from numbers (100, 101, etc) to names. Got no reply :/ One lesser solution is to rename the root trees for the CT's and images of VM's. So I've done mv 100 name; ln -s name 100 in /var/lib/vz/private, I think that'll work. What'd be nice if in...

bump.

Would be even better to not use ID#'s at all. When working on the box seeing config files or dirs, instead of "116" I could see its "CustomerX" and know what Im dealing with. Is there any special reason they're numbers instead of words/tags? Is there any way they could be alphanumeric tags...

Im getting odder behaviour - garbage (hi bit chars) in the conf file and its eating chars from previous lines... # cp 105.conf /root # vzctl set 105 --devnodes dahdi/pseudo:rw --save # diff /root/105.conf /etc/pve/openvz/105.conf 40a41,42 > ost_mac= > A3DEVNODES="dahdi/pseudo:rw " what's...

aha. if it hasnt gotten out of boot yet, its not really started, so shutdown doesnt apply. 'stop' does in fact work, when its still in bios, apologies!

only convenient to have on the GUI because some of us want to delegate sub-access to customers to control their own micro-cloud (quote unquote) of images, etc, without giving root away...

yes of course. pressing it a 2nd time gave a log entry for it - curiously the 2nd attempt had the fail msg come up first while the first attempt was still spinning. eventually they both went to 'fail' (though the first one might have only failed once I killed it from the cmd line actually..)...

how can this be extended to subusers of the VM in the web interface who are given group control over a collection of VMs? this would be fine if hardware could be removed after it gets stuck in BIOS, but it seems to not be possible, even after CTRL-ALT-DEL (hmm, maybe more hardware can be added...

And how do you shutdown a VM that's stuck waiting for a TFTPboot/failed boot? doesnt the virt bios accept ACPI signals? TASK ERROR: VM quit/powerdown failed - got timeout

aha. I suppose the ultimate issue is rsync cant copy deleted files, even if we can get at the content via /proc/*/fd - no way to drop it in the right place in the filesystem for the migrated container to find without some kinda hacky support in the OpenVZ kernel. Actually Im quite suprised that...

few comments down in that thread I posted on the bug: https://bugzilla.openvz.org/show_bug.cgi?id=2242#c33 more specifically: https://bugzilla.openvz.org/attachment.cgi?id=1886&action=diff