• Off-topic
  • Installazione di Windows Server mediante QEMU - Problemi

nexus Ma non c'è modo di farlo partire in autonomia? Come in teoria "raccontano" le guide.

Il fornitore è Oneprovider.com e il server è uno Xeon E5 locato a Parigi.

  • nexus ha risposto a questo messaggio

    elciccion come avevo detto mi son preso un po' di tempo per mettere mano sul ferro: mi son affittato un mese di server dedicato su oneprovider nel mio caso un modesto E3-1220 giusto per minimizzare i costi ma lo scenario applicativo mi pare identico, e in effetti dopo i dovuti smanettamenti il server si avvia con windows gestibile via rdp, nel mio caso ho disabilitato del tutto il fwl ma ovviamente non cambia nulla (in ottica di ambiente di collaudo non certo di esercizio!!!) se lasci attivo ed abiliti in ingresso rdp e magari pure icmp giusto per avere contezza della raggiungibilità anzi in proposito la tua affermazione

    elciccion Il ping non funziona perché è bloccato dal datacenter.

    mi lascia perplesso visto che non è attivo alcun firewall perimetrale infatti il mio server è tranquillamente pingabile (e lo è indipendentemente se avviato con linux o con windows ovviamente)

    comunque

    elciccion mi da come indirizzo locale 10.x.x.x.

    è l'ip privato fornito dalla configurazione di rete che viene impostata con qemu ma come puoi notare

    anche sotto windows l'assegnazione dell'ipv4 pubblico funziona benone via dhcp che è infatti la modalità con cui di base l'ip è assegnato ai server dedicati oneprovider (perlomeno nel caso di 1 ip in gestione) quindi lo script per impostare all'avvio la configurazione statica dell'ip non mi pare necessario nemmeno nel tuo caso

    insomma a parità di scenario (ammesso che è così...e mi pare che lo è, confermi? oppure c'è qualche variabile che non ci hai detto?) mi pare strano che al riavvio (ovviamente s'intende in modalità boot normale) tu non riesci poi a raggiungere l'istanza di windows...non mi vengono in mente cose se cui indagare...diciamo che al tuo posto mi giocherei questa carta...

    ...per tentare di capire lo stato di cose al boot di windows...

    ps. ma a parte tutto sei proprio sicuro sicuro di voler utilizzare windows server come host...? io rimango dell'idea che un bel proxmox come host hypervisor più container/vm vari ed eventuali tra cui magari windows server stesso sia una soluzione più interessante...comunque se riesci a risolvere ti suggerisco di evitare di lasciare esposto rdp su ip pubblico e di connetterti soltanto via vpn

      elciccion Ma da quello che ho capito, tramite questo QEMU avrei ottenuto un'installazione di Windows definitiva, non una vm.

      Eh? Non capisco che senso abbia sta cosa? QEMU gira sul nulla?

      Ma che ha che non va una normalissima VM (che si usa QEMU di solito, quindi 99% stai comunque facendo una VM)

        edofullo anche io lì per lì ero rimasto spiazzato come puoi notare dai miei precedenti commenti ma in questo caso qemu viene furbescamente utilizzato per astrarre tutto l'hardware di installazione tranne l'hdd quindi l'installazione avviene sul disco fisico ed a quel punto quando riavvii la macchina fisica in modalità standard allora l'istanza di windows boota sull'intero hardware fisico, come ho poi confermato con l'ultimo messaggio...si torna quindi al problema iniziale di @elciccion cioè come mai al riavvio non raggiunge l'istanza di windows...cosa che mi lascia piuttosto perplesso dalla via come già detto oneprovider/scaleway sfrutta il dhcp per assegnare l'ip e non credo proprio sia differente nel suo caso...a parte tentare la carta della gestione remota via ipmi, potrebbe comunque provare ad inserire nel task scheduler lo script per assegnare staticamente ip e compagnia bella alla giusta nic (quindi ethernet 2 se il suo server ha una sola nic o al limite ethernet 3 se ne ha due come nel mio caso) in fase di start up dell'istanza windows...avrei anche il dubbio residuale che windows nel suo caso non riconosca la/e nic fisica/he ma se (come nel mio caso) riconosce delle qlogic insomma non penso che il suo server abbia chissà che chipset esoterici...

          nexus Ti ringrazio per la disponibilità dimostrata (e pure per il costo della prova sostenuto).
          Purtroppo, con il passare dei giorni la questione è diventata imminente, per cui ho preferito cancellare il server e puntare su altro (i gestori di Oneprovider hanno gentilmente riaccreditato quasi tutta la somma spesa).

          In ogni caso, la prova non credo sia simile, nel mio caso il server non riuscita ad ottenere né l'ip interno dell'IPMI (come nel tuo caso 62.210...), nè quello esterno pubblico (51.15x..). Usciva proprio un ip privato 10.x.x.x con qemu.

          Il problema infine non si poteva risolvere con l'ultimo screen postato, quello della richiesta IPMI/KVM, perchè a quanto pare quel server non ne era fornito.

          edofullo da quel poco che ho capito, QEMU viene installato sulla distro live di Ubuntu della rescue mode.

          • nexus ha risposto a questo messaggio

            elciccion Ti ringrazio per la disponibilità dimostrata (e pure per il costo della prova sostenuto).

            no problem mi piace smanettare, per qualche euro non vado in bancarotta e ho integrato le mie conoscenze sull'argomento...oh poi magari provo a chiedere recesso e rimborso pure io e via così

            elciccion il server non riuscita ad ottenere né l'ip interno dell'IPMI (come nel tuo caso 62.210...)

            ma poco sotto non scrivi che il tuo server non supportava ipmi...? e comunque quell'ip è quello pubblico, non è "all'interno" di ipmi (che presumo ottenga un suo ip temporaneo assegnato alla seconda eventuale nic in modo da lavorare fuori banda)

            elciccion nè quello esterno pubblico (51.15x..)

            quello è il server dhcp...

            elciccion Usciva proprio un ip privato 10.x.x.x con qemu

            ma certo quello è appunto l'ip privato fornito dalla configurazione nattata di qemu alla nic virtuale..configurazione temporanea che in fase di riavvio in boot normale sparisce...

            elciccion a quel poco che ho capito, QEMU viene installato sulla distro live di Ubuntu della rescue mode

            sì come dicevo prima di fatto qemu ti consente di avere un'astrazione hw temporanea di tutti gli elementi tranne in questo caso l'hdd che rimane quello fisico...vabbuò se hai risolto altrove son contento ma non ti sento molto a fuoco sull'argomento, come d'altronde tu stesso hai ragionevolmente ed onorevolmente ammesso, riconoscere i propri limiti è il primo passo per superarli...a latere se sei interessato a rivedere assieme il risultato dell'approccio iniziale tengo attivo il server e ci possiamo sentire direttamente così magari ti condivido anche una sessione

            oh che poi alla fine io rimango ancora con sta curiosità: cosa ci farai girare su windows server? se si può dire eh

              nexus qemu viene furbescamente utilizzato per astrarre tutto l'hardware di installazione tranne l'hdd quindi l'installazione avviene sul disco fisico ed a quel punto quando riavvii la macchina fisica in modalità standard allora l'istanza di windows boota sull'intero hardware fisico

              Praticamente usa una VM con disk passthrough (permettetemelo) per installare Windows sul disco e poi viene riavviato il server direttamente sul disco (che ora ha windows)?

              nexus a parte tentare la carta della gestione remota via ipmi

              Esatto, tutti i providere che ho visto hanno la gestione remota con una specie di VNC, come anche i server hanno la IDRAC/ILO.

              Strano

              • nexus ha risposto a questo messaggio

                edofullo Praticamente usa una VM con disk passthrough (permettetemelo) per installare Windows sul disco e poi viene riavviato il server direttamente sul disco (che ora ha windows)?

                👍

                edofullo Strano

                beh diciamo che un datacenter con server dedicati privi di ipmi o simile in effetti fa strano...probabilmente ci sono anche dietro logiche commerciali perché di fatto è considerabile una feature premium per così dire...però voglio dire considera che quello da me affittato sempre su oneprovider viene 13 €/mese, insomma non stiamo certo parlando di un server di alto profilo (e per caratteristiche tecniche non lo è manco di striscio infatti)...oh d'altra parte mica tutte le mobo server di gamma medio/bassa supportano nativamente ipmi & simili, in molti casi è necessario installare chipset apposito quindi ci saranno casi di macchine non aggiornate...amen...

                nexus Beh, le mie conoscenze sono quello che sono, e infatti qualcosa avrò sbagliato, altrimenti non eravamo qui... 😅 L'uso è di gestione file e soprattutto seedbox, quindi meglio non parlarne.

                Comunque la prova con gli script nel task scheduler l'avevo fatta, ma al riavvio in normal mode, non andava; tornato sulla rescue mode, e rimesso qemu, mi dava l'ip settato correttamente, ma non c'era connettività all'esterno, infatti non era raggiungibile via rdp.

                Purtroppo credo che la mancanza del KVM sia dovuta esclusivamente all'aspetto economico, perché nell'hosting primario (scaleway), viene fornito in tutte le macchine, compresa quella affittata, mentre su oneprovider no.

                  elciccion L'uso è di gestione file e soprattutto seedbox, quindi meglio non parlarne.

                  Non usano Linux di solito per ste cose?

                  Se ci metti Linux riesci a entrarci in SSH?

                  A parte che pensandoci RDP aperto su Internet mi fa venire male 😅

                  • nexus ha risposto a questo messaggio

                    elciccion le mie conoscenze sono quello che sono

                    certo come quelle di noi tutti, il bello infatti è imparare cose nuove!

                    elciccion gestione file e soprattutto seedbox

                    al di là dell'argomento effettivamente borderline allora io torno al punto iniziale cioè usare linux ma da quanto capisco avevi una certa prescia quindi immagino che sotto windows server tu abbia modo di impostare più rapidamente l'ambiente di lavoro che ti interessa...però....però...........se tu scegliessi di passare come dicevo io a proxmox, che è facilmente installabile su debian per altro, potresti configurarti una vm con windows e fare andare i servizi che ti servono subito lì e poi con calma studiarti un ambiente più nuovo per te in modo da integrare conoscenze e diventare più sicuro nell'utilizzo di quegli strumenti

                    elciccion rimesso qemu, mi dava l'ip settato correttamente

                    mi par di capire che quindi lo script funzionasse ma giustamente in modalità emulata non potevi avere connettività visto che l'ip pubblico viene utilizzato dall'ambiente operativo del rescue mode...mah probabilmente allora windows non riconosceva la nic fisica comunque rimane un mistero...oh allora io cesso tutto eh e amen

                    edofullo Non usano Linux di solito per ste cose?

                    diciamo che esistono script per linux e script per windows in merito a cose di quel tipo...ma come scrivevo poco sopra visto che @elciccion è di base poco pratico con linux ed avendo fretta di quagliare beh è rimasto orientato a windows...

                    edofullo Se ci metti Linux riesci a entrarci in SSH?

                    se intendi "installa una distro linux via qemu - magari diversa da quelle già installabili di base via cruscotto di gestione del server - e poi vedi se al riavvio funziona" beh credo che sia una prova che non interessava al nostro amico visto che appunto vuole avere a che fare il meno possibile con linux...e comunque anche andasse così (per altro nel caso del mio server sarei ottimista) non avresti comunque elementi utili per indagare sull'effettiva causa di malfunzionamento sotto windows...

                    edofullo A parte che pensandoci RDP aperto su Internet mi fa venire male

                    claro, infatti in uno dei miei commenti ho ovviamente accennato al discorso vpn...tra l'altro da questo punto di vista una soluzione proxmox + container/vm consentirebbe anche una gestione più best practice dal punto di vista della sicurezza perchè consentirebbe da una parte di "isolare" la vm con windows e dall'altra volendo di configurare il tutto a monte un bel firewall software in vm

                    Postilla alla discussione: grazie gli spunti di smanettamento offerti da @elciccion ho installato truenas scale come os host senza colpo ferire

                    punto di partenza interessante perché a suo modo truenas è un'ottima alternativa a proxmox anzi per alcuni aspetti è più efficace, con calma verifico poi la possibilità di gestire la stessa configurazione di rete (cioè l'host come nodo di lan e sotto vm una guest che fa firewall/router) che utilizzo con proxmox

                    edit - tra l'altro se esistesse la versione compilata arm64 si potrebbe sfruttare lo stesso barbatrucco su oracle cloud...ok che il tier gratuito offre soltanto 200 GB però insomma come mininas cloud farebbe la sua porca figura considerate le 4 istanze di ocpu e i 24 gb di ram

                      nexus tra l'altro se esistesse la versione compilata arm64 si potrebbe sfruttare lo stesso barbatrucco su oracle cloud...

                      Teoricamente dovrebbe essere OpenSource e dovrebbe essere basato tutto su roba OS che dovrebbe esserci anche per arm64.

                      Sicuramente non sarà semplice però dovrebbe esserci il build system: https://github.com/truenas/scale-build

                      Sicuro su Oracle si possa però? Non hanno qualche sistema per verificare il boot via UEFI o simil?

                      • nexus ha risposto a questo messaggio

                        edofullo Sicuramente non sarà semplice

                        ecco hai c'entrato un punto...smanettare sì ma c'è un livello di potenziale sbattimento/frustrazione che di solito non sono disposto a raggiungere...anche se devo dire che un tentativo si potrebbe pure fare....

                        edofullo Sicuro su Oracle si possa però? Non hanno qualche sistema per verificare il boot via UEFI o simil?

                        e pure l'altro...in effetti io da tempo utilizzo a tempo perso le tre istanze gratuite (le due x64 più la arm64) come vpn road warrior e come ambienti di test ed ovviamente prima di oggi non avevo mai affrontato lo scenario di cui stiamo parlando quindi sì beh credo che prima di tutto andrebbe approfondita meglio quella questione...diciamo che a volte mi piace anche farmi dei film in testa, via...

                        nexus non so se lo conosci ma oltre esiste un altro os molto performante e molto simile a truenas (ad eccezione della tipologia di file system). Si chima openmediavault ed è basato su Debian e anche lì puoi creare VM e vari container. Tra l'altro i requisiti minimi per il funzionamento sono "inferiori" rispetto a quelli richiesti da truenas.

                        • nexus ha risposto a questo messaggio

                          M_Z ti ringrazio per il suggerimento in effetti lo conosco, d'altra parte credo che chiunque bazzichi con questa tipologia di software in un modo o nell'altro incontra sul suo cammino tutti quelli più diffusi, nel complesso lo trovo meno a fuoco (e con alcune delle funzionalità aggiuntive meno mature) rispetto a proxmox truenas o unraid ma è un prodotto valido e per quanto mi riguarda anche flessibile perche come tu hai ricordato si basa su debian che è da tempo immemore la mia distro of choice (non a caso anche se gli scenari d'uso generali sono differenti dai miei io preferisco truenas scale al core in quanto su base debian), tra l'altro con la 6.x hanno finalmente rinnovato la webui, poi vabeh prevedibilmente si riesce ad installare anch'esso con il barbatrucco famoso

                          ah ai giovani anziani come me sarano sicuramente brillati gli occhietti alla vista della parola evidenziata nell'immagine sopra...per non parlare poi della schermata di errore di nginx...

                          😍

                          • M_Z ha messo mi piace.

                          Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈
                          P.I. IT16712091004 - info@fibraclick.it

                          ♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile